Ну по большому счету автор все-таки прав - FastCGI не ускоряет php ;-)
Но вот какие доводы он приводит, это конечно песня.
> Старые скрипты, написанные с расчетом на CGI, приходится дорабатывать, чтобы
они могли работать в FastCGI-окружении. Действительно, ведь раньше скрипт
стартовал каждый раз "с чистого листа", а теперь ему приходится иметь дело с
тем "мусором", который остался от предыдущего запроса.
Тут автор имеет ввиду perl, хотя и не говорит об этом. В php есть понятие
"SAPI", это интерфейс-прослойка, скрывающая от скрипта все особенности веб
сервера, а в perl ничего такого нет. Самое смешное, что автор прекрасно об
этом знает, судя по тексту далее. А вот неискушенный читатель уже воспринял
вышесказанное на счет php. Как в анекдоте, "осадочек остался".
> FastCGI имеет значительный недостаток: новый запрос начинает обрабатываться
не в "чистом" окружении, а в том, которое осталось "с прошлого раза". Если в
скрипте имеются утечки памяти, они постепенно накапливаются до тех пор, пока
не произойдет крах. Это же касается и ресурсов, которые забыли освободить
(открытые файлы, соединения с БД и т. д.). Есть и еще один недостаток: если
код скрипта изменился, то приходится как-то сообщать об этом FastCGI-серверу,
чтобы он "убил" все свои процессы и начал заново.
То же самое. Правильнее было бы написать "Везде кроме как в php, FastCGI имеет
значительный недостаток ...". Но автор продолжает придерживаться выбранной
стратегии - оправдать название статьи путем замалчивания неудобных фактов ;-)
> Вероятно, вы слышали, что PHP тоже можно запускать в режиме FastCGI, и что
так делают многие нагруженные проекты (Мамба, некоторые проекты Mail.Ru и т.
д.). Это якобы дает "существенный прирост" производительности, потому что
FastCGI экономит время инициализации скрипта и подключения библиотек. Не
верьте! В действительности поддержка FastCGI в PHP имеет чисто номинальный
характер.
Автор, не верь слухам ! php как FastCGI был выбран нами в Мамбе не для
"существенного прироста" производительности, а чтобы не использовать Apache,
который, как известно, плохо подходит для высоконагруженных сайтов.
> Конечно, вы можете запустить PHP FastCGI-сервер и даже заставить nginx или
lighttpd работать с ним напрямую, однако прирост скорости, который вы от
этого получите, заключается (в лучше случае) в экономии времени создания
одного процесса ОС (т.е. системного вызова fork).
Конечно, это не так. Время системного вызова fork - ничто по сравнению со
временем на exec (про которое автор умолчал) + время на инициализацию php
процесса, которое тратится на каждый запрос в режиме CGI и отсутствует в
FastCGI.
Кстати, я не понял зачем автор переходит на сравнение с CGI. Ведь в mod_php
нет fork-a на каждый запрос, а гонять CGI на production это клиника.
Самое занятное - далее по тексту упоминается эта самая "экономия одного
fork-а". Хотя понятно, это такой дискуссионный прием - взять незначительную
фичу и выдать ее за единственное, несущественное преимущество:
> Много это или мало, экономия одного fork-а? Судите сами. Рядовая
Linux-машина может выполнять тысячи fork-вызовов в секунду благодаря
технологии copy-on-write для страниц памяти, применяемой во всех современных
ОС. Это меньше 1 мс на fork! В то же время, даже простой PHP-скрипт обычно
требует десятков миллисекунд на свою работу. Пытаясь экономить на одном
fork-е, вы "экономите на спичках".
Следите за руками - вот так просто сложить у неискушенного читателя мнение о
том, что все преимущество FastCGI, по сути есть "экономия на спичках" ;-)
Дальше еще веселее:
> Ходят слухи, что PHP гораздо быстрее загружает один большой файл, чем десять
маленьких того же суммарного объема.
Да, слухи это серьезный довод в серьезной статье.
В общем, у меня сложилось смешанное впечатление о сабж. Вроде как она об
акселераторах, но автор так все смешал в кучу...
Я вряд ли я могу порекоммендовать ее к прочтению, особенно тем, кто пытается
беспристрастно разобраться в сути вопроса и преимуществах технологии FastCGI.
--
Andrei Nigmatulin
GPG PUB KEY 6449830D
Now I lay me down to sleep(3)
Pray the OS my core to keep
If I die before I wake
Pray the Disk my core to take
> Если от теории перейти к практике, есть ли подробные замеры
> производительности первого и второго?
Дело не в скорости как таковой, хотя она как минимум не меньше чем в
mod_php. Дело в расходе памяти, что крайне полезно.
Я как-то сравнивал, по очереди запускал сайт на mod_php и php-fpm -
выигрыш по скорости был от 10 до 50% в пользу последнего, при (примерно)
вдвое меньшем расходе памяти. Сейчас у меня крутится кучка сайтов на
"сервере" с 256М памяти, так там даже осталось место на мемкеш.
может вот эти доводы и выложить в форуме обсуждения.
Дима Котеров - известный разработчик и имеет достаточный авторитет, и своим заблуждением он вводит в заблуждение тысячи разработчиков...
естественно есть (под рукой нет),
достаточно сравнить по объему памяти занимаемых процессами httpd (64М) & nginx (64K)
о, я кстати готов составить "ответ чемберлену" по результатам этой
дискуссии. но ближе в выхожным. мне уже кидали эту статью, я её глядел
по диагонали - но щас посмотрел внимательнее - куча куча неточностей.
обидно, конечно, что куча народу читает...
wbr,
fisher
Apache + fastcgi может представлять разве что академический интерес, но не
практический.
> Интересует именно работа на тяжелых движках(Мамба, Битрикс, и т.п.) с
> большой нагрузкой на достаточно мощных машинах.
Например, можно взять пару популярных cms и залить живые данные с имеющихся
сайтов.
> Под эксперименты есть практически не используемая машина 2xqxeon
> e5335@2GHz/16GRAM/RAID10
> под сам веб-сервер.
> Плюс можно выделить почти такой же под базы данных. Дистрибутив - Debian 4
>
> Интересует именно методология бенчмарка, оптимальные конфиги веб-серверов и
> т.п.. Когда-то я пользовался скриптами, которые в несколько потоков
> проигрывали access_log апача, хотелось бы что-то такое, что можно
> воспроизвести каждому, но не чистую синтетику.
Попробуйте поиграться с flood или siege - чем дольше и точнее их настраиваешь
тем меньше тест будет похож на синтетику ;-)
Тестировать каждую конфигурацию надо минимум двадцать-тридцать минут
непрерывной нагрузки, желательно в несколько заходов, с разным кол-вом
одновременных обращений. Параллельно снимать показания load average, vmstat и
pinba, сохранять это для последующего анализа в файлы.
В общем, нудная и тяжелая работа. Но выводы безусловно будут очень ценными ;-)
> Если кто-то может что-то посоветовать, то я бы погонял бенчмарки, оформил и
> выложил в инет.
>
> Большое спасибо.
>
> 2008/6/19 Alexey A. Rybak <alexey...@gmail.com>:
> > 2008/6/19 Alexandre Kalendarev <aka...@mail.ru>:
> > > Андрей,
> > >
> > > может вот эти доводы и выложить в форуме обсуждения.
> > >
> > > Дима Котеров - известный разработчик и имеет достаточный авторитет, и
> >
> > своим заблуждением он вводит в заблуждение тысячи разработчиков...
> >
> >
> > о, я кстати готов составить "ответ чемберлену" по результатам этой
> > дискуссии. но ближе в выхожным. мне уже кидали эту статью, я её глядел
> > по диагонали - но щас посмотрел внимательнее - куча куча неточностей.
> > обидно, конечно, что куча народу читает...
> >
> > wbr,
> > fisher
--
Однако, apache-worker с fastcgi регулярно выпадал.... (или, вернее,
фастцжи выпадал) ;/ вы не ошиблись на счет worker ?
Там где позволяют условия и требования проектов nginx + php-fpm +
xcache the best (imho)!
а mod_php уже пожалуй как атавизм.
--
Best Wishes,
PAIX-UANIC | SK3929-RIPE
получите -
php 5.2.6 as nginx+FCGI+php-fpm+xcache+memcached
ab -n 1000 -c 5 http://test.***.ru/
Requests per second: 31.51 [#/sec] (mean)
Requests per second: 29.04 [#/sec] (mean)
Requests per second: 32.32 [#/sec] (mean)
Requests per second: 31.39 [#/sec] (mean)
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
3 1 40100 18260 55416 400568 0 0 66 715 165 9394 73 11 10 5
6 1 40100 18352 55496 401324 0 0 20 796 164 8121 72 11 11 6
7 0 40100 16444 55628 402220 0 0 49 764 203 8002 70 12 12 7
5 0 40104 19448 55000 397064 0 0 24 683 220 7642 72 10 13 5
3 2 40104 20716 55076 397700 0 0 40 1216 340 6902 52 9 28 11
3 1 40104 20096 55152 398516 0 0 20 857 159 8644 69 11 13 7
Parse Time: 0.1049 s / 8 SQL
Memory 548984
SQL connection time 0.0064
SQL time 0.0028
PHP time 0.0957
php 5.2.6 as nginx+Apache2+mod_php+xcache+memcached
ab -n 1000 -c 5 http://***.ru/
Requests per second: 16.39 [#/sec] (mean)
Requests per second: 16.11 [#/sec] (mean)
Requests per second: 16.72 [#/sec] (mean)
Requests per second: 16.07 [#/sec] (mean)
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
5 0 40108 17740 55356 398340 0 0 58 519 137 4264 74 5 15 7
6 1 40108 16952 55464 398768 0 0 30 798 209 5228 77 5 14 4
3 1 40100 15596 55564 399244 0 0 39 775 197 4377 73 6 15 6
5 0 40100 15324 55620 399752 0 0 40 304 215 4958 78 5 12 4
7 1 40100 14668 55700 400180 0 0 27 914 168 4372 76 4 15 5
3 1 40100 14612 55772 400696 0 0 45 423 276 4394 76 4 14 5
4 1 40100 16556 55128 398788 0 0 32 501 141 4330 81 5 10 4
Parse Time: 0.1798 s / 8 SQL
Memory 3013980
SQL connection time 0.0020
SQL time 0.0117
PHP time 0.1661
А так, аб - это очень примитивно и относительно.
Как писали в одной книжке "Искусственные тесты дают искусственные
результаты."
Реально нельзя сравнить с рабочим сайтом, на который, к примеру,
уникальных 100 клиентов законекчено одновременно...
поди на каждого активного клиента будем в памяти тушку апача иметь с
модом пыха.
- можно ли свести дисковую активность к нулю и повторить, т.к. жесткий диск
это большой тормоз, он искажает benchmark
- база данных на другом хосте ?
- memcached на другом хосте ?
- ab запускается с другого хоста ?
- можно еще проверить "-c 15" и "-c 50" ?
--
крайне сложно, рабочий сервер, десяток сайтов...
> это большой тормоз, он искажает benchmark
> - база данных на другом хосте ?
на том же
> - memcached на другом хосте ?
на том же
> - ab запускается с другого хоста ?
с того же
> - можно еще проверить "-c 15" и "-c 50" ?
увы, ab сломался, пишет
apr_sockaddr_info_get() for ***.ru: Unknown error 14642 (14642)
Разумеется, это быстрая и возможно неточная "прикидка". Так вот сходу
организовать правильный тестовый ящик увы, не могу. Попробую что-то
пообъективней организовать, но...
Сейчас надо мной будут все потешаться....
ab -n 1000 -c 5 http://***.ru/
Requests per second: 31.60 [#/sec] (mean)
ab -n 1000 -c 5 http://test.***.ru/
Requests per second: 33.30 [#/sec] (mean)
ab -n 1000 -c 15 http://***.ru/
Requests per second: 35.76 [#/sec] (mean)
Requests per second: 35.34 [#/sec] (mean)
ab -n 1000 -c 15 http://test.***.ru/
Requests per second: 36.00 [#/sec] (mean)
Requests per second: 35.97 [#/sec] (mean)
ab -n 1000 -c 50 http://***.ru/
Requests per second: 36.96 [#/sec] (mean)
ab -n 1000 -c 50 http://test.***.ru/
Requests per second: 35.15 [#/sec] (mean)
Суть дела - в прошлом тесте кеш скриптов xcache у апача был сильно
фрагментирован, а сейчас я делал тест сразу после рестарта апача и php-fpm
В общем, каюсь и бью себя пяткой по голове.
Кроме того - при -c 50 возникает вопрос - а сколько дочек наплодил апач?
лимит там стоит 150. А php-fpm запущен с 10 воркерами в одном пуле.
Так что тестирование дело хитрое.
> Лично я после прочтения его книги ещё о PHP4, а также беглого взляда в
> код библиотек, которые яростно распостраняет - больше его за
> авторитета не считаю.
> (даже года так 2 назад не поехал на PHPConf потому что он там
> собирался выступать :)
ну, это ты зря, там и без него было много полезного...
смысл есть сравнить именно fcgi php_mod c акселлераторами и без
думаю корреляция скорости акселлераторов будет сильной и мало зависить от того в каком режиме он работает
хотя если есть время, то поему бы и не сравнить... главное чтоб результаты стали "достоянием народа"
тогда от них будет польза
Дмитрий, 50-я набла это вообще отдельный разговор. По ней отдельно есть
серьезные замечания.
> > Я как-то сравнивал, по очереди запускал сайт на mod_php и php-fpm -
> > выигрыш по скорости был от 10 до 50%
>
> Reverse proxy использовали? Настройки Apache ковыряли?
> В общем, точные замеры (естественно, после правильной настройки) - в
> студию.
Я вполне допускаю что разброс в скорости мог быть такой, в первую очередь
из-за того, что в случае с php-fpm вся сэкономленная память используется под
файловый кэш.
> > не использовать Apache, который, как известно, плохо подходит для
> > высоконагруженных сайтов
>
> Сдается мне, "...вы просто не умеете их готовить".
> Не Apache не подходит. А надо отделять мух от котлет и ставить reverse
> proxy перед апачем, чтобы медленных клиентов срезать и расходы памяти
> снизить. Еще раз: работа типичного PHP-скрипта (если это не "Hello,
> world") занимает минимум несколько десятков миллисекунд, из которых
> значительную часть отнимает возня с байт-кодом. На этом фоне экономить
> ДЕСЯТЫЕ ДОЛИ миллисекунды - просто смешно.
Дело как раз не в медленных клиентах. Дело в overhead который неизбежен при
обработке сетевых соединений по модели apache - "один процесс - один клиент".
Этот overhead возникает из-за необходимости быстро переключаться между
процессами на каждый io ready.
Для nginx этого overhead нет, потому что там модель "один процесс - много
клиентов".
Кстати, из 50-й наблы я могу сделать вывод что именно этот overhead вы
постоянно упускаете из виду:
> Эту же проблему с "медленными клиентами" имеют в виду, когда говорят
"статику надо отдавать nginx-ом". Статика сама по себе вообще не является
проблемой: даже самый захудалый apache на самой захудалой машине способен
обрабатывать несколько тысяч статических запросов в секунду. Если у вас не
фотохостинг, этого достаточно за глаза: как вы понимаете, отдавать 10000
запросов статики в секунду через apache или 11000 запросов в секунду через
nginx (т.к. нагрузка идет в основном на диски) — разницы для скорости проекта
практически никакой нет. Выигрыш с nginx тут опять только из-за "медленных"
клиентов, которые "срезаются" при помощи reverse proxy.
-- конец цитаты --
> >> Ходят слухи, что PHP гораздо быстрее загружает один большой файл, чем
> >> десять маленьких того же суммарного объема.
> >
> > Да, слухи это серьезный довод в серьезной статье.
>
> Вы следующее предложение читали, или так, придираетесь?
> А оно гласит: "Я решил проверить это утверждение...".
В данном случае просто придираюсь.