статья по поводу fastcgi
kay
господа, раздавим автора контраргументами.
1) автор не использовал php-fpm + unix sockets
2) тестировал на ноутбуке...
Andrei Nigmatulin
Ну по большому счету автор все-таки прав - 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
kay
On Jun 19, 5:22 am, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
wrote:
> "существенного прироста" производительности, а чтобы не использовать Apache,
> который, как известно, плохо подходит для высоконагруженных сайтов.
производительности первого и второго?
alex946
> Если от теории перейти к практике, есть ли подробные замеры
> производительности первого и второго?
Дело не в скорости как таковой, хотя она как минимум не меньше чем в
mod_php. Дело в расходе памяти, что крайне полезно.
Я как-то сравнивал, по очереди запускал сайт на mod_php и php-fpm -
выигрыш по скорости был от 10 до 50% в пользу последнего, при (примерно)
вдвое меньшем расходе памяти. Сейчас у меня крутится кучка сайтов на
"сервере" с 256М памяти, так там даже осталось место на мемкеш.
Alexandre Kalendarev
может вот эти доводы и выложить в форуме обсуждения.
Дима Котеров - известный разработчик и имеет достаточный авторитет, и своим заблуждением он вводит в заблуждение тысячи разработчиков...
Alexandre Kalendarev
> > Автор, не верь слухам ! php как FastCGI был выбран нами в Мамбе не для
> > "существенного прироста" производительности, а чтобы не использовать Apache,
> > который, как известно, плохо подходит для высоконагруженных сайтов.
>
> Если от теории перейти к практике, есть ли подробные замеры
> производительности первого и второго?
естественно есть (под рукой нет),
достаточно сравнить по объему памяти занимаемых процессами httpd (64М) & nginx (64K)
Alexey V. Karagodov
ни особых цифр ни каких то подробных описаний тестов, ничего ...
смысл высе.... статьи вообще какой?
P.S.: кг/ам какой то получился
Alexey V. Karagodov
Alexey A. Rybak
>
> Андрей,
>
> может вот эти доводы и выложить в форуме обсуждения.
>
> Дима Котеров - известный разработчик и имеет достаточный авторитет, и своим заблуждением он вводит в заблуждение тысячи разработчиков...
>
о, я кстати готов составить "ответ чемберлену" по результатам этой
дискуссии. но ближе в выхожным. мне уже кидали эту статью, я её глядел
по диагонали - но щас посмотрел внимательнее - куча куча неточностей.
обидно, конечно, что куча народу читает...
wbr,
fisher
Alexander Naydenko
Хотелось бы попробовать такой список:
1.Apache+PHP-FCGI(FCGID)(c eaccelerator и без)
2.Apache+mod_php(с eacclerator и без)
3.Apache+php-fpm/fcgid(с eacclerator и без)
4.LightHTTPD+PHP-FCGI(FCGID)(c eaccelerator и без)
5.LightHTTPD+PHP-fpm/fcgid(c eaccelerator и без)
6.nginx+PHP-FCGI(FCGID)(c eaccelerator и без)
7.nginx+PHP-fpm/fcgid(c eaccelerator и без)
Интересует именно работа на тяжелых движках(Мамба, Битрикс, и т.п.) с большой нагрузкой на достаточно мощных машинах.
Под эксперименты есть практически не используемая машина 2xqxeon e5335@2GHz/16GRAM/RAID10 под сам веб-сервер.
Плюс можно выделить почти такой же под базы данных. Дистрибутив - Debian 4
Интересует именно методология бенчмарка, оптимальные конфиги веб-серверов и т.п.. Когда-то я пользовался скриптами, которые в несколько потоков проигрывали access_log апача, хотелось бы что-то такое, что можно воспроизвести каждому, но не чистую синтетику.
Если кто-то может что-то посоветовать, то я бы погонял бенчмарки, оформил и выложил в инет.
Большое спасибо.
--
С уважением,
Александр Найденко
-------------------------------------
Andrei Nigmatulin
> Мгм. Господа. Я бы хотел сделать какой-нибудь более-менее четкий бенчмарк
> разных способов работы с PHP на нагруженных серверах.
>
> Хотелось бы попробовать такой список:
> 1.Apache+PHP-FCGI(FCGID)(c eaccelerator и без)
> 2.Apache+mod_php(с eacclerator и без)
> 3.Apache+php-fpm/fcgid(с eacclerator и без)
> 4.LightHTTPD+PHP-FCGI(FCGID)(c eaccelerator и без)
> 5.LightHTTPD+PHP-fpm/fcgid(c eaccelerator и без)
> 6.nginx+PHP-FCGI(FCGID)(c eaccelerator и без)
> 7.nginx+PHP-fpm/fcgid(c eaccelerator и без)
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
--
fixxxer
wrote:
>
> > Мгм. Господа. Я бы хотел сделать какой-нибудь более-менее четкий бенчмарк
> > разных способов работы с PHP на нагруженных серверах.
>
> > Хотелось бы попробовать такой список:
> > 1.Apache+PHP-FCGI(FCGID)(c eaccelerator и без)
> > 2.Apache+mod_php(с eacclerator и без)
> > 3.Apache+php-fpm/fcgid(с eacclerator и без)
> > 4.LightHTTPD+PHP-FCGI(FCGID)(c eaccelerator и без)
> > 5.LightHTTPD+PHP-fpm/fcgid(c eaccelerator и без)
> > 6.nginx+PHP-FCGI(FCGID)(c eaccelerator и без)
> > 7.nginx+PHP-fpm/fcgid(c eaccelerator и без)
>
> Apache + fastcgi может представлять разве что академический интерес, но не
> практический.
всеми причиндалами в .htaccess и (2) запуск php с uid/gid
пользователя, схема squid|oops -- apache2worker+mod_fcgid -- php-
fastcgi как раз вполне подходит. По крайней мере, когда я этим
занимался (года 3 назад), лучше ничего не придумал :)
Sergej Kandyla
> On Jun 20, 4:03 am, Andrei Nigmatulin <andrei.nigmatu...@gmail.com>
> wrote:
>
>> On Friday 20 June 2008 03:01, Alexander Naydenko wrote:
>>
>>
>>> Мгм. Господа. Я бы хотел сделать какой-нибудь более-менее четкий бенчмарк
>>> разных способов работы с PHP на нагруженных серверах.
>>>
>>> Хотелось бы попробовать такой список:
>>> 1.Apache+PHP-FCGI(FCGID)(c eaccelerator и без)
>>> 2.Apache+mod_php(с eacclerator и без)
>>> 3.Apache+php-fpm/fcgid(с eacclerator и без)
>>> 4.LightHTTPD+PHP-FCGI(FCGID)(c eaccelerator и без)
>>> 5.LightHTTPD+PHP-fpm/fcgid(c eaccelerator и без)
>>> 6.nginx+PHP-FCGI(FCGID)(c eaccelerator и без)
>>> 7.nginx+PHP-fpm/fcgid(c eaccelerator и без)
>>>
>> Apache + fastcgi может представлять разве что академический интерес, но не
>> практический.
>>
>
> Для shared хостинга, при наличии одновременных требований (1) апач со
> всеми причиндалами в .htaccess и (2) запуск php с uid/gid
> пользователя, схема squid|oops -- apache2worker+mod_fcgid -- php-
> fastcgi как раз вполне подходит. По крайней мере, когда я этим
> занимался (года 3 назад), лучше ничего не придумал :)
nginx + apache-prefork + mod_fastcgi(fcgid) -- php-fastcgi
Однако, apache-worker с fastcgi регулярно выпадал.... (или, вернее,
фастцжи выпадал) ;/ вы не ошиблись на счет worker ?
Там где позволяют условия и требования проектов nginx + php-fpm +
xcache the best (imho)!
а mod_php уже пожалуй как атавизм.
--
Best Wishes,
PAIX-UANIC | SK3929-RIPE
alex946
получите -
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
Sergej Kandyla
>> Было бы неплохо увидеть также тесты с xcache
>>
>
> получите -
>
>
> php 5.2.6 as nginx+FCGI+php-fpm+xcache+memcached
>
> ab -n 1000 -c 5 http://test.***.ru/
>
вообщемто, то я для целостности картины сказал.
А так, аб - это очень примитивно и относительно.
Как писали в одной книжке "Искусственные тесты дают искусственные
результаты."
Реально нельзя сравнить с рабочим сайтом, на который, к примеру,
уникальных 100 клиентов законекчено одновременно...
поди на каждого активного клиента будем в памяти тушку апача иметь с
модом пыха.
Andrei Nigmatulin
- можно ли свести дисковую активность к нулю и повторить, т.к. жесткий диск
это большой тормоз, он искажает benchmark
- база данных на другом хосте ?
- memcached на другом хосте ?
- ab запускается с другого хоста ?
- можно еще проверить "-c 15" и "-c 50" ?
--
alex946
> диск
крайне сложно, рабочий сервер, десяток сайтов...
> это большой тормоз, он искажает benchmark
> - база данных на другом хосте ?
на том же
> - memcached на другом хосте ?
на том же
> - ab запускается с другого хоста ?
с того же
> - можно еще проверить "-c 15" и "-c 50" ?
увы, ab сломался, пишет
apr_sockaddr_info_get() for ***.ru: Unknown error 14642 (14642)
alex946
> вообщемто, то я для целостности картины сказал.
>
> А так, аб - это очень примитивно и относительно.
> Как писали в одной книжке "Искусственные тесты дают искусственные
> результаты."
>
> Реально нельзя сравнить с рабочим сайтом, на который, к примеру,
> уникальных 100 клиентов законекчено одновременно...
> поди на каждого активного клиента будем в памяти тушку апача иметь с
> модом пыха.
Разумеется, это быстрая и возможно неточная "прикидка". Так вот сходу
организовать правильный тестовый ящик увы, не могу. Попробую что-то
пообъективней организовать, но...
alex946
Сейчас надо мной будут все потешаться....
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 воркерами в одном пуле.
Так что тестирование дело хитрое.
Alexander Naydenko
Alexandre Kalendarev
Alexandre Kalendarev
Rauan Maemirov
добавить еще APC? :)
On Jun 21, 1:21 am, "Alexander Naydenko" <aanayde...@gmail.com> wrote:
> Господа, на следующей неделе у меня планируется достаточно свободного
> времени и я собираюсь поплотнее заняться бенчмарками. Если у кого нибудь
> будут предложения по тестам, конфигам и методологии - с удовольствием приму
> к сведению.
>
Voituk Vadim
On Jun 19, 10:01 am, Alexandre Kalendarev <akal...@mail.ru> wrote:
> Дима Котеров - известный разработчик и имеет достаточный авторитет, и своим заблуждением он вводит в заблуждение тысячи разработчиков...
Лично я после прочтения его книги ещё о PHP4, а также беглого взляда в
код библиотек, которые яростно распостраняет - больше его за
авторитета не считаю.
(даже года так 2 назад не поехал на PHPConf потому что он там
собирался выступать :)
--
Vadim Voituk
http://voituk.kiev.ua/
Александр Лозовюк
--
C уважением, Александр Лозовюк
Alpha-Beta-Release Blog
http://abrdev.com
Voituk Vadim
Ну для начала стоит полистать книгу Котерова о PHP4 (издательства BHV)
- там "перл на перле".
К сожалению на этой книге выросли поколения PHP-кодеров (в том числе и
для меня она была первой по PHP)
Когда ко мне собеседование приходили люди и несли характерную ахинею -
я их прямо спрашивал не учили ли они PHP по этой книге - ещё ни один
не ответил отрицательно.
Что конкретно было не так в коде - уже не помню (было это года 4 назад
наверное), но помню что смотрел реализацию класса JsHttpRequest а ещё
чуть позже код какой-то "прослойки" к БД - в обоих случаях были
банальные школьные ошибки кодирования, ужасный стиль написания и
количество глюков соверщенно несоизмеримое с публичностью продукта. В
обоих случаях прийшлось отказываться от его разработок (с достаточно
интересными как на то время идеями).
Про выступление автора статьи на PHPConf - даже говорить не хочется :(
Вот неприятные впечатления и до сих пор гнетут, и авторитет автора в
моих глазах подорван ощутимо.
Опять же дело было давно и как оно обстоит сейчас - не знаю (один
апологет Котерова даже убеждал что Дима опомнился и все что было
раньше переделал правильно :) Но судя по статье про FastCGI - не
опомнился.
Вопросы?
On Jun 21, 11:22 pm, "Александр Лозовюк" <aleks.rai...@gmail.com>
wrote:
> равнозначного, чтобы подтвердить свои слова? а то как то неправильно
> получается.
>
kay
других. надеюсь результаты не будут настолько искусственными.
стата nginx показывает до 120 запросов в секунду (для реальных тестов
достаточно?). в данный момент есть два результата:
- с xcache - высокая нагрузка на hdd, т.к. он у меня IDE и один.
- и без него - высокая нагрузка на проц и mysql.
что не удивительно.
уже заказал парочку WD на 10000 об/мин. поставлю их в raid 0.
обдумываю как организовать прозрачное переключение с apache. графики
будут строиться в munin.
Alexander Naydenko
тел. +7 495 506 97 01
Rauan Maemirov
разницую Может если вместо apc поставить что-то другое, например
xcache или eAccelerator, будет быстрее(надежнее/стабильнее)?
On Jun 22, 4:57 pm, "Alexander Naydenko" <aanayde...@gmail.com> wrote:
> Готов с удовольствием расширить список тестируемых конфигураций. Пишите ваши
> варианты.
>
Alexandre Kalendarev
> On Jun 19, 10:01 am, Alexandre Kalendarev <akal...@mail.ru> wrote:
> > Дима Котеров - известный разработчик и имеет достаточный авторитет, и своим заблуждением он вводит в заблуждение тысячи разработчиков...
> Дима Котеров - известный популист а не разработчик.
> Лично я после прочтения его книги ещё о PHP4, а также беглого взляда в
> код библиотек, которые яростно распостраняет - больше его за
> авторитета не считаю.
> (даже года так 2 назад не поехал на PHPConf потому что он там
> собирался выступать :)
ну, это ты зря, там и без него было много полезного...
Alexandre Kalendarev
> Про выступление автора статьи на PHPConf - даже говорить не хочется :(
>
> Вот неприятные впечатления и до сих пор гнетут, и авторитет автора в
> моих глазах подорван ощутимо.
"на прошлой конфе он облажался, посмотрим, как будет на этот раз"...
этого раза не состоялось ;)
Alexandre Kalendarev
> Готов с удовольствием расширить список тестируемых конфигураций. Пишите ваши
> варианты.
>
> 2008/6/21 Rauan Maemirov <raua...@gmail.com>:
>
> > Интересно, почему берутся только eAccelerator и xCache? Может стоит
> > добавить еще APC? :)
> >
смысл есть сравнить именно fcgi php_mod c акселлераторами и без
думаю корреляция скорости акселлераторов будет сильной и мало зависить от того в каком режиме он работает
хотя если есть время, то поему бы и не сравнить... главное чтоб результаты стали "достоянием народа"
тогда от них будет польза
PHP Club
Прикольный совет.. я представляю как чайники начнут его
применять..
>>Наконец, применяйте функцию set_include_path(), чтобы код подключения библиотек выглядел вот так
>>require_once "Some/Library.php";
On 19 июн, 00:51, kay <kay.d...@gmail.com> wrote:
> http://www.dklab.ru/chicken/nablas/49.html
> господа, раздавим автора контраргументами.
> 1) автор не использовал php-fpm + unix sockets
> 2) тестировал на ноутбуке...
kay
http://pentarh.com/wp/2008/07/11/test-results-apache-vs-php-fcgi/
Alexandre Kalendarev
автор поспешил с выводами и обещал переделать тесты.
grigori
On 21 июн, 12:37, Rauan Maemirov <rauan1...@gmail.com> wrote:
> Интересно, почему берутся только eAccelerator и xCache? Может стоит
> добавить еще APC? :)
для данного проекта.
А скорость отличается на 1-2% и зависит от настроек.
Можно отключить проверку обновления файлов, в APC есть ускорение
require_once, в Xcache есть маленькая оптимизация кода. Тут нюансов
конфигурации намного больше, чем разницы в скорости.
dmitry.koterov
Память здесь некоторый оффтопик, об этом 50-я набла:
http://dklab.ru/chicken/nablas/50.html
> Я как-то сравнивал, по очереди запускал сайт на mod_php и php-fpm - выигрыш по скорости был от 10 до 50%
Reverse proxy использовали? Настройки Apache ковыряли?
В общем, точные замеры (естественно, после правильной настройки) - в
студию.
> не использовать Apache, который, как известно, плохо подходит для высоконагруженных сайтов
Сдается мне, "...вы просто не умеете их готовить".
Не Apache не подходит. А надо отделять мух от котлет и ставить reverse
proxy перед апачем, чтобы медленных клиентов срезать и расходы памяти
снизить. Еще раз: работа типичного PHP-скрипта (если это не "Hello,
world") занимает минимум несколько десятков миллисекунд, из которых
значительную часть отнимает возня с байт-кодом. На этом фоне экономить
ДЕСЯТЫЕ ДОЛИ миллисекунды - просто смешно.
> Конечно, это не так. Время системного вызова fork - ничто по сравнению со временем на exec (про которое автор умолчал) + время на инициализацию php процесса, которое тратится на каждый запрос в режиме CGI и отсутствует в FastCGI.
Похоже на правду, но, действительно, к сравнению mod_php и fastcgi-php
это имеет малое отношение.
Поэтому из статьи я данную фразу убираю, спасибо за замечание.
>> Ходят слухи, что PHP гораздо быстрее загружает один большой файл, чем десять маленьких того же суммарного объема.
> Да, слухи это серьезный довод в серьезной статье.
Вы следующее предложение читали, или так, придираетесь?
А оно гласит: "Я решил проверить это утверждение...".
On 19 июн, 08:30, "alex946" <alex...@zokov.net> wrote:
> > Если от теории перейти к практике, есть ли подробные замеры
> > производительности первого и второго?
>
> Дело не в скорости как таковой, хотя она как минимум не меньше чем в
> mod_php. Дело в расходе памяти, что крайне полезно.
>
> Я как-то сравнивал, по очереди запускал сайт на mod_php и php-fpm -
> выигрыш по скорости был от 10 до 50% в пользу последнего, при (примерно)
> вдвое меньшем расходе памяти. Сейчас у меня крутится кучка сайтов на
> "сервере" с 256М памяти, так там даже осталось место на мемкеш.
dmitry.koterov
так не угодил.
Кстати, неплохо бы еще и учесть http://dklab.ru/chicken/img/younotyou.gif
Книга "Самоучитель PHP4" вышла в 2001 году (мне тогда было 19 лет).
Семь лет прошло с тех пор, любой код давно устарел и покрылся
плесенью.
Не ездить на phpConf из-за этого - мягко говоря, странно.
On 22 июн, 00:22, "Александр Лозовюк" <aleks.rai...@gmail.com> wrote:
> а что, собственно, в его коде не так, и что вы можете показать
> равнозначного, чтобы подтвердить свои слова? а то как то неправильно
> получается.
>
Andrei Nigmatulin
> > Дело не в скорости как таковой, хотя она как минимум не меньше чем в
> > mod_php. Дело в расходе памяти, что крайне полезно.
>
> Память здесь некоторый оффтопик, об этом 50-я набла:
> http://dklab.ru/chicken/nablas/50.html
Дмитрий, 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 гораздо быстрее загружает один большой файл, чем
> >> десять маленьких того же суммарного объема.
> >
> > Да, слухи это серьезный довод в серьезной статье.
>
> Вы следующее предложение читали, или так, придираетесь?
> А оно гласит: "Я решил проверить это утверждение...".
В данном случае просто придираюсь.
tri...@gmail.com
можно наковырять до хороших показателей. Ведь как-то сущестсовали и
существуют высоконагруженные проекты на apache =) Соответственно, с
проксей перед ним, взять тот же lighttpd или 0w.
Лично я уже пару лет пользуюсь nginx и fastcgi, мои проекты не такие
уж и высоконагруженные =) Просто это удобней, чем mod_php, лично мне.
А что до Дмитрия, мне кажется, ему просто лень переписывать свой
денвер под nginx+php-fpm, вот и отстаивает апач =) Но от прогресса то
не уйти, обиженный Дмитрий после этой дискуссии, уверен, в скором
времени соберет новый денвер, на lighttpd+spawn-php, чтобы Нигматулину
и Сысоеву пусто было =))
Alexandre Kalendarev
Денвер - это популизм для новичков...Хотя, сам начинал с первой версии, за что Диме огромное спасибо...
всоконагруженные проеты разрабатываются изнаально на том софте, на котором будет стоять продакшен...Увы - это не винда однозначно.
Алексей С.
alekc...@gmail.com
Используя его они совершенно не понимают принципов работы системы.
Элементарных вещей потом в конфиг внести не могут.
Alexandre Kalendarev
а лучше вывеси обявление на пхп.ру или пхпклаб. Сдесь новичков нет, разговор в пустоту.