Nginx

на серверах 70+ мегабит при коде 200 выдаётся не весь ответ, а кусок, и соединение закрывается (0.5.35 версия, на ней точно есть такой глюк, в 0.4. постоянно)

Soft-Com писал:

на серверах 70+ мегабит при коде 200 выдаётся не весь ответ, а кусок, и соединение закрывается

насколько я знаю этим страдали только сервера под linux и только с включенным keepalive, пропатчивалось в версиях 0.6.32 и 0.7.0 и в последних версиях уже не проявляется

keepalive помоему не влияет, но в остальном точно так.

Но осадок остался ...

shahfil писал:

а нафиг там апач-то вообще? у меня все сиджи без него живут спокойно, связка nginx+php/fastcgi и никаких проблем

А если стоит смарттумбс, то можно будет без апача обойтись? (смарттумб - пхп зазенденый)

Johnny писал:

А если стоит смарттумбс, то можно будет без апача обойтись? (смарттумб - пхп зазенденый)

Блин, говорю же, использование зазенденых скриптов PHP под fastcgi неоправдано, т.к. получается практически обычный CGI режим, который намного тормознутее apache/mod_php, который был собран прямыми руками.

сильно сомневаюсь.

на сиджевом сервере 30+ мегабит использование apache2+fcgid+suexec+свои_патчи_безопасности вместо apache2+libphp4 даёт прирост производительности на 10-15%, а именно:
IOWAIT падает с 6% до 2%
CPU Usage падает с 32% до 22%
и при этом на софтварном рейде еще и падает дисковая активность на 1%-5%

всё в worker_mpm

с нгинксом ситуация абсолютно аналогичная(mod_php не рулит)

P.S.
понятно что время исполнения скрипта через mod_php меньше, но думаю нет большой разницы, выполнится out.php/in.cgi/etc/ за 0.15 или за 0.155 секунды

На фхг сервере 300 МБит+ (3 млн в сутки, До 500 запросов в секунду) FCGI решения от php-fpm и light-httpd сосут и захлебываются в коннекшенах перед префорковым апачем + mod_php. Правда в апаче кроме мод_пхп все остальное тупо выключено.

можно МРТГ по LA,IOwait,и кол-ву процессов апача посмотреть?

Soft-Com писал:

IOWAIT падает с 6% до 2%

Еще бы падает. Ты бы AllowOverride в апаче выключил бы.

Soft-Com писал:

CPU Usage падает с 32% до 22%

Это не mime_magic случаем?

Soft-Com писал:

можно МРТГ по LA,IOwait,и кол-ву процессов апача посмотреть?

Неа, прийдется поверить на слово. Сервер итак еле дышит. Но вовсе не из-за апача. Незачем опять эту хуету ставить (FCGI).

я так понимаю пентарх в сторону nginx/fastcgi-php по совсем другой причине плюётся, не так ли?

Прежде чем на продакшн ставить всякие патчи, надо всё-таки хотя бы документацию читать под эти самые патчи? А то будет "хуета", "сосёт"...

Последний раз редактировалось: allendale (09/07/08 в 00:45), всего редактировалось 1 раз

double

Не, реально сосет как ни крути. Я уж и крутил и вертел, апач рулит по управлению IPC. На продакшин ставил, да. Но нагрузку давал импульсную - подкрутил, переключил, посмотрел - хуйня, переключил взад.

Если ты такой умный, где мне взять на тестовой платформе такую нагрузку? Я имею ввиду мощную и распределенную? У меня ботнетов в загашнике нет.

Pentarh писал:

Не, реально сосет как ни крути. Я уж и крутил и вертел, апач рулит по управлению IPC. На продакшин ставил, да. Но нагрузку давал импульсную - подкрутил, переключил, посмотрел - хуйня, переключил взад.

а что крутить-то? написали же на 2гб памяти ставить 512 php процессов это монстроидальность. И написали тут же - ебись в рот конями периодический периодический перегруз ботами - сделать 100 процессов и хер с ним. php-fpm ПОКА не в состоянии контролировать кол-во процессов.
Да и нормальное планирование вроде никто не отменял. Если комп уже СЕЙЧАС не справляется с текущими задачами, то что будет когда нагрузка "немного" вырастет?

Цитата:

Если ты такой умный, где мне взять на тестовой платформе такую нагрузку? Я имею ввиду мощную и распределенную? У меня ботнетов в загашнике нет.

я не умный, но точно знаю - было бы желание - а средства найдутся всегда.
а если нет желания, начинаются проблемы, типа "сосёт" :-)

PS. Кстати насчёт твоей проблемы с seek latency на винтах - может есть смысл таки прикупить пару-тройку ssd ? Цены на них упали довольно хорошо, может по скорости линейного чтения они и сосут, но в рандоме, насколько я знаю они ОЧЕНЬ быстры, что делает их незаменимыми для толпы мелких файлов.

allendale писал:

а что крутить-то? написали же на 2гб памяти ставить 512 php процессов это монстроидальность. И написали тут же - ебись в рот конями периодический периодический перегруз ботами - сделать 100 процессов и хер с ним. php-fpm ПОКА не в состоянии контролировать кол-во процессов.

Слушай, ну вот не пизди и не пиздим будешь. Ты нифига не знаешь ситуацию, а строишь из себя тут мега ебаната.

allendale писал:

Да и нормальное планирование вроде никто не отменял. Если комп уже СЕЙЧАС не справляется с текущими задачами, то что будет когда нагрузка "немного" вырастет?

Когда мне просто надо было посмотреть разницу между тем как четыре машины отдают по отдельности и четыре в режиме зеркала, меня апач не устраивал в первом случае. Мне надо было переключить режим кластера, посмотреть и переключить назад - ВСЕ! Какое в пизду планирование?

allendale писал:

Кстати насчёт твоей проблемы с seek latency на винтах - может есть смысл таки прикупить пару-тройку ssd ? Цены на них упали довольно хорошо, может по скорости линейного чтения они и сосут, но в рандоме, насколько я знаю они ОЧЕНЬ быстры, что делает их незаменимыми для толпы мелких файлов.

А может ты мне Фибре чэнел и инфинибанд посоветуешь еще поставить? GPFS спасет мир и две сотни сата винтов.

Ты там хоть 20 детей ставь хоть 1000.на таком трафе, в режиме постоянного респауна, производительность фастцги будет сводиться к производительности цги, т.е. В жопу. В то время как грамотно собранный апач в качестве бекенда со своим годами отточенным механизмом ИПЦ будет рвать все фастцги спаунеры, которые работают с неоптимизированными под фастцги скриптами.

Вы бы в рассылке nginx-а подняли этот вопрос, люди бы почитали, посоветовали чего...

Не, я все таки не удержусь запостить ссылку на тему PHP FastCGI
http://dklab.ru/chicken/nablas/49.html

http://groups.google.com/group/highload-php-ru/browse_thread/thread/2919ab6e985e1c00
и хорош уже изображать из себя мега ебаната (c) твой.

http://pentarh.com/wp/2008/07/11/test-results-apache-vs-php-fcgi/

Pentarh писал:

http://pentarh.com/wp/2008/07/11/test-results-apache-vs-php-fcgi/

Десятые доли в обработке при ЗНАЧИТЕЛЬНО МЕНЬШЕМ сжирании памяти и процессора, что в конечном счёте сказывается в обработке значительно большего количества данных, это конечно показатель :-)

про то, что fastcgi == cgi, я деликатно помолчу. и про форки тоже.

да о чем вообще можно судить по тесту, который меряет скорость работы mod_php/php_fpm на выполнении скрипта работающего с удаленной БД?

allendale писал:

Десятые доли в обработке при ЗНАЧИТЕЛЬНО МЕНЬШЕМ сжирании памяти и процессора, что в конечном счёте сказывается в обработке значительно большего количества данных, это конечно показатель :-)

Кхе, там разница в два процесса = разница в потребляемой памяти ) Не надо ля-ля

shahfil писал:

да о чем вообще можно судить по тесту, который меряет скорость работы mod_php/php_fpm на выполнении скрипта работающего с удаленной БД?

А че, нынче все скрипты работают с локальной? ) Да даже если с локальной? Что меняется? Время коннекта? Соглашусь, но оно меняется для всех тестов, разница остается.

А скрипт рабочий, работает с 4 машин с одной базой. Это для тебя дико?

Да, насчет "Apache рвет FPM" я пожалуй погорячился. Ну как минимум не отстает, если руки вправить прямо. Это было мое субъективное мнение, которое выработалось в ходе практики.

FPM думаю можно применять на некоторых весьма узких задачах. С большим количеством воркеров он ведет себя весьма херово. Получается, выставлять больше воркеров чем нужно - большие расходы в памяти и кпу, выставлять меньше - время ответа херится.

Мне не в кайф бы было постоянно присматривать за FPM, руками ему воркеры корректировать. Зачем если это прекрасно умеет делать apache, и по параметрам они примерно равны?

да не, все нормально, подход классический - "отмеряем микрометром, отмечаем мелом и отрубаем топором"