ЦМС/фремворк готовая выдержать 1кк/сутки

[venetu]

Там, где кеширование невозможно, проще разбить страницу на блоки и закешировать три четверти тем же самым nginx. Он умеет server-side-includes, так что можно спокойно закешировать, к примеру, всю страницу кроме надписи вверху справа "привет, DOLARiON!".

Итого при выводе страницы у тебя будет всего пара sql запрос вместо десятков. И опять же, именно это и есть та причина, по которой возможно не придется вникать в дебри таблиц и их связей, и не копаться в коде, который их там обрабатывает. Скорость очень увеличится и без этого. Именно за счет того, что посещаемость апача упадет, а не за счет каких-то там оптимизаций или хитрых алгоритмов.

Да, у вас по-прежнему будет тормознутая база, по-прежнему неоптимальный код (в который вы даже и не заглядывали), просто вызываться этот код будет фактически раз в минуту, а то и реже - а такую нагрузку любой сервак вполне потянет. И по sql, и по файлам.

И да, это практически панацея. У нас на хостинге больше двух сотен сайтов, там стоит такой зоопарк из разных cms и самописных поделок, что просто жуть. Каждую из них оптимизировать - жизни не хватит. А с nginx нагрузка снимается в сотни раз.

 

[masto]

FastCGI - До сих пор непойму почему ему оды поют, 3-5% разница получается в производительности и приходится менять стиль написания, кое-что работает не так.

А как работает rewrite мне даже с бубном понять неудалось, точне работать то заставил но не понял принципа.

ngnix - согласен полезная штука но там тоже нюансы в настройке.

2 DOLARiON

Нет таких запросов которые нельзя закешировать, возможно заюзать мемкачед стоит для запросов которые используются больше всего ?

1. FastCGI - единственный способ установки PHP (и других трансляторов) на nginx.
2. Ничего переписывать не надо, всё прекрасно работает (за исключением функций специфичных для mod_php, но без низ спокойно можно обойтись и грамотные кодеры их никогда не используют).
3. rewrite к CGI никакого отношения не имеет.

Там, где кеширование невозможно, проще разбить страницу на блоки и закешировать три четверти тем же самым nginx. Он умеет server-side-includes, так что можно спокойно закешировать, к примеру, всю страницу кроме надписи вверху справа "привет, DOLARiON!".

Итого при выводе страницы у тебя будет всего пара sql запрос вместо десятков. И опять же, именно это и есть та причина, по которой возможно не придется вникать в дебри таблиц и их связей, и не копаться в коде, который их там обрабатывает. Скорость очень увеличится и без этого. Именно за счет того, что посещаемость апача упадет, а не за счет каких-то там оптимизаций или хитрых алгоритмов.

Да, у вас по-прежнему будет тормознутая база, по-прежнему неоптимальный код (в который вы даже и не заглядывали), просто вызываться этот код будет фактически раз в минуту, а то и реже - а такую нагрузку любой сервак вполне потянет. И по sql, и по файлам.

И да, это практически панацея. У нас на хостинге больше двух сотен сайтов, там стоит такой зоопарк из разных cms и самописных поделок, что просто жуть. Каждую из них оптимизировать - жизни не хватит. А с nginx нагрузка снимается в сотни раз.

Не надо путать хостинг и высоконагруженную систему - это абсолютно разные вещи.
Просто установка nginx - это временное решение, которое всего лишь подымет планку повыше, но не панацея.
Если хочется выжать максимум из имеющегося железа, лезть в код всё равно придётся (в том числе и для организации кэшей).

PS

Скорость очень увеличится и без этого. Именно за счет того, что посещаемость апача упадет, а не за счет каких-то там оптимизаций или хитрых алгоритмов.

Интересно каким образом скорость увеличится, если Apache вообще не используется?

 

[venetu]

Апач используется! Апач, php, mysql - все остается как и было. Просто сверху ставится nginx. НЕ как замена кому-либо из вышеперечисленных.

Если подкручивать php как цегайку к nginx, можно здорово все порушить. Придется вникать, чего оно там вдруг перестало работать. Да еще ж и попробуй найди, где именно оно перестало работать, в каких случаях.. А то с виду работает, а копнуть глубже - какие-то глюки странные, и не понятно когда возникают..

Тут вся соль в том, что мы вообще не прикасаемся к тому, что и так работает.

 

[aktuba]

Бред... 200 сайтов с 0-ой посещаемостью??? У меня на одном хостинге 30 сайтов висит, на которых и посещаемость есть. Работает на апаче и все летает. А есть, допустим, nnm.ru, который тоже стоит на nginx-е, но его это не спасает. Спасает только продуманный код и хорошее внутреннее кеширование, построенное на memcashe.

ssi? да поможет, если правильно применять. если на странице есть динамика, до 90% - это комментарии. если они храняться в базе - ssi тут не сильно поможет. если же в файлах, то поможет, но надо правильно сохранять, а это уже внутренняя архитектура.

Вывод - пишет человек, который ни разу не работал с большими нагрузками на одной системе. Может все-таки стоит хотя бы почитать о них, прежде чем давать советы?

На будущее - апач тоже может работать с ssi . Тогда зачем вообще нужен nginx в вашей схеме? =)

 

[masto]

nginx only + PHP/FastCGI - прекрасно работают сами по себе без всякого Apache. Для поиска ошибок есть логи и дебаг, точно также как и на Apache.

Тут вся соль в том, что мы вообще не прикасаемся к тому, что и так работает.

Ну да, и кэши волшебным образом создаются сами.

1. Подскажите как научить CMS использовать memcached без переписки кода, если она изначально этого не умеет.
Если ты это можешь сделать, то просто волшебник.
2. Зачем ставить Apache (прекрасный, но тяжёлый сервер), если есть nginx, lighttpd, jetty. На хостинге всё понятно, но речь ведётся о собственном железе и одном проекте.

nginx - не панацея, это ВРЕМЕННОЕ решение, способное поднять производительность на определённую величину.

Оптимизация всей архитекруры в целом и исполняемого кода в частности - позволит поднять производительность гораздо выше.

А вообще рекомендую ознакомится с понятиями "экстенсивное" и "интенсивное" развитие.

 

[aktuba]

Во! Правильно изложено, хотя не полностью. Ну и насчет FastCGI я бы так не заявлял. Недавно только статья была у Котерова, в которой он просто разгромил FastCGI. Там тоже есть не понятные места, но в целом все правильно написано.

 

[masto]

Со статьей Котерова не знаком, но лично мой опыт применения FastCGI никаких непонятных мест не выявил.

И FastCGI применяется не для повышения производительности (хотя применительно к PHP показывает лучшие результаты чем suexec/suphp, сопоставимые с производительностью mod_php), просто иногда это единственный доступный способ запуска транслятора.
А повысить производительность PHP (без оптимизации кода скриптов) могут только кэши типа APC, xCache, eAccelerator и т.п., поскольку отпадает необходимость компиляции при повторных вызовах.

 

[aktuba]

Для просмотра ссылки Войди или Зарегистрируйся. Советую почитать и ее, и комментарии к ней.

 

[XeonN]

1. Подскажите как научить CMS использовать memcached без переписки кода, если она изначально этого не умеет.
Если ты это можешь сделать, то просто волшебник.

В принципе несложно, в основном сменить класс работы с базой, но не везде это можно сделать безболезнено и не все движки готовые этому поддаются.

А без переписки кода это невозможно, хотя смена класса на некоторых движках у меня занимала 20-30 минут и еще несколько часов на отлов багов. Это самый простой способ.

 

[aktuba]

В принципе несложно, в основном сменить класс работы с базой, но не везде это можно сделать безболезнено и не все движки готовые этому поддаются.

А без переписки кода это невозможно, хотя смена класса на некоторых движках у меня занимала 20-30 минут и еще несколько часов на отлов багов. Это самый простой способ.

Это пр условии, что написано с классами, а не разбросаны все запросы по всем файлам, что встречается очень часто.