Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: FastCGI PHP
>> У пхп свой менеджер процессов, оно не убьется "апстенку", а
>> перезапустит свой дочерний процесс, который достиг лимита.
> Несмотря на описанное в доке поведение (на заборе, как известно, тоже много
> чего написано, а за ним дрова лежат) куча говнокода под названием PHP повела
> себя так, как ей больше нравилось. Именно что с потрясающей регулярностью
> убивала себя ровно через это количество запросов.
Мы подняли свой движок на FCGI. Так вот. Всё нормально, никто не
умирает, возможно есть перезапуск, но мы его (естественно) не
замечаем. Мы тестировали десять минут, эмулировался заход 100
пользователей одновременно. Без картинок и прочего. На странице -
баннерокрутилка с 4 баннерами, которые ротейтся, вывод новостей, меню
и мелочи.
В итоге:
nginx + Apache/mod_php - 11962 запроса, доступность - 98.47%
nginx + FCGI/php - 13117 запросов, доступность - 100%
при этом резко упал расход памяти. Параметры: PHP_FCGI_CHILDREN=7,
PHP_FCGI_MAX_REQUESTS=10000. Движки полностью идентичные (ничего
переписывать не пришлось, завелось и так). Единственная разница -
mod_php работает с Zend Optimizer, fcgi-php - с eaccelerator последней
версии. PHP одинаковый - 5.1.4
> Естественно первая мысль была насчет кривых лап запускателей, а не пускателей.
> Однако Гугль показал, что запускатели не одиноки в своей проблеме. Героически
> решать проблемы софта, у которого до сих пор торчат уши от девичьей фамилии
> Personal Home Page (каких бы фреймворков сейчас ни придумывали) никому
> совершенно не хотелось, поэтому просто запустили внешней оберткой. В том
> числе и
> обсуждаемой выше. Работало стабильно и работает до сих пор.
Как видно, за эти 10 минут FCGI обработало запросов больше значения
PHP_FCGI_MAX_REQUESTS (кстати, мы проводили испытания и при значении
1000, результаты очень похожи).
|
