LINUX.ORG.RU
ФорумAdmin

[php-fpm][история успеха] Я ждал этого несколько лет :D

 ,


0

2

Обнаружил тут, что в застабилизировавшемся в Gentoo php-5.3.3, появилась поддержка php-fpm.

Пересобрал php, десяток минут чтения конфиго, настройки и тестов - и готово. Боевой нагруженный виртхост с какой-то подозрительной сторонней баннерной системой крутится в песочнице. Всё это на православном lighttpd, без всяких тормозов Апачевского mpm_itk. Да ещё и с динамическим управлением количества серверов, в отличии от классического fast-cgi. С повиртхостовой конфигурацией PHP. Со своими логами, в.т. slow-вызовов. И т.п.

По-моему, это самое полезное нововведение в PHP со времён выхода PHP5.

Продолжаю растаскивание по песочницам других виртхостов :)

★★★★★

Взрослый вроде человек, а такой херней занимаешься. Учи пайтон @ юзай джангу

anonymous
()
Ответ на: комментарий от anonymous

Чёрт. У меня же ЖК. Его от жира тяжело отмывать.

KRoN73 ★★★★★
() автор топика

>php-5.3.3

Через 11 дней ждем в сквизе :)

nnz ★★★★
()
Ответ на: комментарий от post-factum

>php-fpm также часто используют с nginx. Почему не он?

Исторически больше люблю lighttpd :) Конечно, можно назвать и объективные критерии, из-за которых он (заметно быстрее отдаёт статику, не ломают конфиги с новыми версиями, изначально содержал fast-cgi менеджер, так что никаких 500-х ошибок из-за отвалившегося бэкенда и т.д. и т.п.), но основной причиной, безусловно, является то, что Лайти я использовал уже тогда, когда Энжинкс ещё за пределами Рамблера неизвестен был :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Sylvia

>а какие USE для

lighttpd

php



Именно для php-fpm:
www-servers/lighttpd +fastcgi
dev-lang/php +fpm

Дальше можно ориентироваться на статью http://wiki.firstvds.ru/index.php/Высокопроизводительный_web-сервер_вариант_2 с поправкой на то, что у php-fpm.conf сейчас конфиг не XML-ный, а php.ini-style. Но там всё понятно.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от n1

Попробуй поднять на дешёвом VPS apache2+mod_php. «Дешёвый» означает «мало ОЗУ».

post-factum ★★★★★
()
Ответ на: комментарий от n1

А где можно увидеть прожорливого обжору в действии, от которого отходить надо будет ? =)

lighttpd, статика:

# wget -S --spider http://localhost
[...]
  Content-Length: 757
  Server: lighttpd/1.4.26
[...]
# ab -n5000 -c50 http://localhost/
[...]
Requests per second:    14371.20 [#/sec] (mean)
Time per request:       3.479 [ms] (mean)
Time per request:       0.070 [ms] (mean, across all concurrent requests)
Transfer rate:          14441.37 [Kbytes/sec] received

apache2, mpm_itk, статика:

# wget -S --spider http://localhost:8184/
[...]
  Server: Apache
  Content-Length: 757
[...]
# ab -n5000 -c50 http://localhost:8184/
[...]
Requests per second:    675.97 [#/sec] (mean)
Time per request:       73.968 [ms] (mean)
Time per request:       1.479 [ms] (mean, across all concurrent requests)
Transfer rate:          666.73 [Kbytes/sec] received

Это на mpm_itk. mpm_prefork работает раз в 10 быстрее, но всё равно получится вдвое медленнее, чем у Лайти. Кстати, nginx тоже есть под рукой, простаивает:

# wget -S --spider http://localhost:8443/
  Server: nginx/0.8.52
  Content-Length: 757
[...]
Requests per second:    25818.04 [#/sec] (mean)
Time per request:       1.937 [ms] (mean)
Time per request:       0.039 [ms] (mean, across all concurrent requests)
Transfer rate:          24406.12 [Kbytes/sec] received

Хм. Прикольно. Но это вышло на пустом конфиге. На боевом получалось раза в полтора меньше, чем у Лайти. Хотя нужно попробовать будет поиграть с настройками, может за последний год заметно скорость вытянули. И падения бэкенда с php-fpm не страшно, теперь за ним сам PHP следить будет.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Слышал от знакомого админа в крупном банке, что именно nginx+php-fpm там держит часть нагрузки. А часть — как-то по-хитрому настроенная связка apache2+nginx.

post-factum ★★★★★
()
Ответ на: комментарий от Divius

>что такое и в чём профит?

Если у тебя на хостинге несколько сайтов от разных юзеров, и нужно не дать скриптам одного юзера лазить по каталогам другого, то нужно как-то заставлять php работать от разных юзверей. Раньше было два пути: использовать тормозной модуль Апача mpm_itk, который позволял целиком запустить часть Апача с правами конкретного юзера и неуклюжий вариант с php-fastcgi, когда для каждого юзера вводился отдельный fastcgi-сервер.

Теперь (это не считая других вкусностей) «улучшенный вариант fast-cgi» появился прямо в самом PHP.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Divius

>Профит в новой формулировке?;)

Нет, в том, что теперь вместо N серверов под каждого юзера можно иметь один сервер. Кроме того, позволяющий динамически реагировать на изменения нагрузки (pm.min_spare_servers, pm.max_spare_servers). Плюс к этому ряд специфических фишек, типа жёсткого лимита на операции, логгирования медленных скриптов и т.п.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от post-factum

Ну да, там много вкусностей.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от post-factum

> Больше всего мне лично нравится жёсткое указание количества worker'ов — по одному на CPU, например.

это типа удобно когда не знаешь сколько ядер у тебя? забавно

anykey_mlya
()
Ответ на: комментарий от post-factum

а т.е. он сам следит за тем, чтобы процесс четко выполнялся на определенном цп, или это все таки такая извращенная система указания общего числа worker'ов ?

anykey_mlya
()
Ответ на: комментарий от post-factum

>жёсткое указание количества worker'ов — по одному на CPU, например

А CFS может гарантировать, что на каждом ядре в любой момент времени работает один и только один воркер? Если нет — профит от фичи получается весьма виртуальным.

nnz ★★★★
()
Ответ на: комментарий от anykey_mlya

Общего числа. При достаточной нагрузке планировщик процессов раскидывает потоки на разные ядра.

post-factum ★★★★★
()
Ответ на: комментарий от maxkit

>Обычно [..] динамическое всё - apache

Это только при древнем legacy-проекте и/или ленивом админе :) Профита в динамике под Апачем - никакого.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Я знаю и сам всегда с этим борюсь. Но многие люди панически боятся нового.

maxkit
()
Ответ на: комментарий от KRoN73

статья немножко устарела, по конфигам, но тем не менее сориентироваться несложно,
спасибо еще раз, нашла время, поставила попробовать, все работает, обкатаю несколько приложений, если все будет хорошо, то буду понемножку на других серверах заменять апач+mod_php на лайти с php-fpm

по памяти статистика весьма себе неплохая по сравнению с 28 Мб RSS на форк апача

root 31239 0.0 0.1 23024 3388 ? Ss 16:03 0:00 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf
lighttpd 31240 0.0 0.1 23024 3040 ? S 16:03 0:00 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf
lighttpd 31241 0.0 0.1 23024 3040 ? S 16:03 0:00 /usr/bin/php-fpm -y /etc/php/fpm-php5/php-fpm.conf
lighttpd 31403 0.0 0.0 4452 1468 ? S 16:05 0:00 /usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
lighttpd 31406 0.0 0.2 23116 6020 ? Ss 16:05 0:00 /usr/bin/php-cgi
lighttpd 31408 0.0 0.1 23116 2384 ? S 16:05 0:00 /usr/bin/php-cgi
lighttpd 31409 0.0 0.2 23116 6016 ? Ss 16:05 0:00 /usr/bin/php-cgi
lighttpd 31414 0.0 0.1 23116 2380 ? S 16:05 0:00 /usr/bin/php-cgi
lighttpd 31415 0.0 0.2 23116 6020 ? Ss 16:05 0:00 /usr/bin/php-cgi
lighttpd 31416 0.0 0.1 23116 2384 ? S 16:05 0:00 /usr/bin/php-cgi
lighttpd 31417 0.0 0.2 23116 6020 ? Ss 16:05 0:00 /usr/bin/php-cgi
lighttpd 31418 0.0 0.2 23372 4676 ? S 16:05 0:00 /usr/bin/php-cgi

Sylvia ★★★★★
()
Ответ на: комментарий от JFreeM

Попробуй развернуть Java-приложения на стрёмненьком VPS-хостинге под openVZ.
У меня на домашнем сервачке с гигом оперативы (т.е. максимально 1Гб вирт. памяти в контейнере) даже пустой glassfish заводится через раз. А о установке на него аппликухи и речи быть не может.
А с PHP всё становится доступным и быстрым ;)

some-body ★★
()
Ответ на: комментарий от some-body

И да, в последнее время почему-то всё больше и больше ненавижу Java.
PS. Прошу прощения за оффтоп.

some-body ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.