ПОщечина любителям FastCGI

Я про файлы и не спорю. А привел результаты своего апгрейда. Тестом это действительно назвать нельзя, т.к. не соблюдены условия тестирования (напп. одинаковые версии софта). Тем не менее даже навскидку мой результат не совпадает вот с этим выводом:

Да, в теории, если сравнивать apache+mod_php+eacc и apache+fastcgi+eacc то может быть эта фраза несла бы какую то пользу, однако php с FastCGI запускают не из любви к искусству (читай не из любви к супер-технологии FastCGI ), а для того чтобы использовать легкий фронтенд. Получается, толку от статьи (кроме исследования влияния объединения файлов в include ) ноль :)

См. у другого человека похожие на мои результаты.

http://forum.dklab.ru/viewtopic.php?p=157355#157355

Попробуйте провести чистый тест на сервере, где нет рабочих проектов. Правда на самом деле спор неочем.

Связка nginx+apache+eaccelerator есно будет уступать fastcgi на рабочем сервере, т.к. апач ведь всё-равно вызывается и хавает память. Причем если загружено много модулей - то хавает просто оочень много памяти.. Пусть и на короткое время.

Поэтому нужно понимать, что если не ограничить кол-во процессов апача отталкиваясь от свободной оперативной памяти на сервере - то при всплеске нагрузки (тот же тест допустим) серверу будет плоха

По поводу коммента на форуме dklab: делать тест на сервере с рабочими проектами под нагрузкой, это вообще извините меня что-то нецензурное. Ещё нецензурнее потом полученные результаты выкладывать в паблик

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

Ну тут вы немного загнули. У них там отображение работает на пхп, а вот вычисления я думаю нет :) Как бы мне лично не нравился пхп...

А по поводу Котерова, то видя как тормозит (или по крайней мере тормозил ранее) МойКруг его советов по оптимизации не хочется слушать :) Хотя, как автор самоучителя по пхп, его никто, имхо не превзошёл.

как велосипедиста его никто не превзошёл :)

Pilat добавил 08.08.2008 в 16:22

Пока php не научится убирать за собой после запросов - никакой fastcgi ему не поможет, ИМХО.

Пока, к сожалению, не до этого... В любом случае, тесты проводились в разное время много раз (и даже глубокой ночью), при разной паразитной нагрузке ( она очень низкая в любом случае, сервер реально простаивает). Я же не зря написал диапазоны полученных результатов, как раз разброс типа 35-37 и 60-70 и вызван паразитной нагрузкой, искажающей результаты тестов. Запущенные процессы я видел, боты сервер не насиловали...Своп системой не использовался (памяти 1гб хватало)

К сожалению, отдельного сервака нет под рукой...Про свои тесты отвечу, как уже сказал, проверялось при нулевой нагрузке и несколько раз в разное время суток.

Лишней памяти не бывает, даже если вы свой сервер под завязку набьете, все равно имеет смысл оптимизировать и освобожденные ресурсы системы пустить на что-нибудь полезное. Вот взять задачи с которыми я работаю - Drupal, там можно очень много всего, memcached, APC memory cache, MySQL query cache, файловый кеш, и под все нужна память, чем больше тем лучше.

Да, мои проекты щас далеки от 70 и даже от 20 запросов в секунду, зато я спокойнее живу, зная, что мой сервер выдержит гораздо большую пиковую нагрузку (например, т.н. Digg-effect ) чем раньше

Хех... Ну я ж о чём... Под каждую задачу - свой инструмент. :)

Лично мне глубоко фиолетово, на ПХП сайт делать или на С++. Если задача позволяет сделать быстро и с достаточным качеством реализовать её на ПХП, то лично мне совершенно всё равно, если кто-то считает ПХП не кошерным. :) Если в рамках этой задачи есть _маленькая_ подзадача, скажем, отдача информеров для высоконагруженных сайтов со сбором статистики, то она делается на Си + кеширование в файлах или мемкеше и скрипт на 1,5 килобайта _естественно_ рвёт по производительности всё что можно. При этом мы получаем разумный баланс между удобством саппорта сайты на ПХП и производительностью подсистем, где эта производительность реально востребована.

Santyago

А если добавить сюда, что хороших, открытых и бесплатных CMS/CMF на Си не наблюдается, а все больше на скриптовых языках, получим ,что проще (и выгоднее) для большинства проектов взять готовое решение и доработать под свои нужды, а рассуждения, что лучше, оставить теоретикам-программистам ( типа анонимусов на ЛОРе, которые устраивают холиварс какой язык круче) и очень большим компаниям, которые могут себе позволить держать свой штат программистов и разрабатывать весь функционал с нуля на том языке, который больше подходит для задачи ;)

О! Полностью согласен! :)

Раз уж пошла такая пьянка, никто не знает как решить проблему потребления памяти в разросшихся движках http://groups.google.com/group/highload-php-ru/browse_thread/thread/53a1be8c49ae827d/f645e7764e5bc517 ?

(если внимательно читать, там написано почему memcached не выход)

Memcached - выход, если в него помещать предгенеренную страницу и отдавать nginx