Comments 59
Недавно ставил fpm c php 5.3.1, пришлось немного попариться :) Это правильно что фпм решили в кор включить, меньше мороки.

Кстати для 5.3.х eAccelerator заводится только с дев версии 0.9.6.
Мне пришлось перейти на АПЦ, так как еакселератор в последней версии (для 5.3.x) выбросил все, кроме кеширования опкодов.(((
Ну мне собственно только это от него и надо :)

Я вот честно даже не знаю, помогал тот же оптимизатор или нет, специально исследования не проводил.
А мне очень нужны shared values, использую их вместо мемкеша, т.к. намного быстрее оного.)))
Задача, которая была поставлена — добавление поддержки fpm в используемую в debian стабильную версию php, каковой сейчас является 5.2.6. Чтобы было во-первых как можно меньше каких-то несовместимостей. Ну и во-вторых, чтоб не приходилось самим залатывать все уязвимости и баги, которые в php интерпретаторе находят. У debian явно более квалифицированные QA/Security команды, которые отслеживают все эти проблемы и выпускают фиксы. Не каждый готов этим заниматься. У нас нет столько времени, про dotdeb.org — не знаю. Мы планируем делать сборки с добавлением fpm патча для последующих обновлений в стабильной ветке.

По деталям:

Конкретно в этой версии пропатчен CGI SAPI, но мы также смотрим вариант использования более позднего патча с отдельным fpm sapi для 5.2.6, как это было сделано в более поздних версиях. Потом выложим в том же репозитарии в testing или unstable, если все будет в порядке. Плюс, думаю, в репозитарий также положим сборку для php 5.2.11, которая сейчас идет в debian-testing, хотя, насколько я знаю, пара подобных сборок уже есть. С остальными версиями — будет видно позже. Зависит от многого, в первую очередь — от команды debian.

ИМХО! не стал бы называть 5.2.6 стабильной. Как минимум устаревшей. Стоит лишь заглянуть в changelog между 5.2.6 и 5.2.11

Лично я всегда на production собирал nginx + php(+fpm) из исходников последних версий. php 5.3 стояло на одном из вирт-хостов nginx за несколько месяцев до выхода релиза — вполне стабильно.

Спасибо вам ребята за вашу работу. Я, конечно продолжу собирать сам. А вот за Debian очень рад.
Ну она стабильная по оценке debian. :-) По той же самой оценке у них 5.2.11 — testing. Чтобы сравнивать, нужно смотреть не только changelog между этими версиями, но и список патчей в debian/patches. Тем не менее, для 5.2.11 мы тоже добавим, так как оно довольно востребованно.
Ну как я уже говорил — меня nginx и php уже не заставить из пакетов устанавливать. Но вам, за вашу работу большой РЕСПЕКТ!
Когда планируется добавить в репозитари версию для testing? или уже не планируете?
и как такая связка по скорости на виртуалке? есть реальные тесты?
ЗЫ: админка уже появилась? обещали к концу ноября ;)
С eAccelerator гоняли phpbb на 480 MHz CPU / 256 Mb RAM. 20 параллельных запросов — 12.32 trans/sec. Более полные сравнительные тесты с apache/mod_php сделаем позже, когда выйдет из беты и можно будет выделить на тестирование достаточно времени.
Webmin/DirectAdmin/ISPManager можно на свой VDS в любой момент самому поставить. А отдельный ЦУ пока не появился. Удивительно, но реальных запросов на ЦУ очень мало, поэтому в плане работ на первое место все время что-то другое становится, типа SSD для VDS или вот PHP-FPM.

Хотя в ЦУ есть свой важный функционал, хотя бы подключение отладочных и инсталляционных машин, поэтому надолго его откладывать не будут.
я как раз имел в виду админку, в котором можно было общаться с сапортом, смотреть счета, оплачивать услуги, менять настройки ресурсов и т.д.
всё замечательно, но каждый раз что-то узнавать через форму обратной связи — не очень удобно.
ЗЫ: спасибо кстаии за сервис — дешево и качественно… перелез с выделанного сервака на виртуальный, разницы не заметил, а платить в 4 раза меньше теперь =)
В репозитории есть eAccelerator (0.9.5.3) под этот патч, как раз тот, который используется в пресете.
Хм… может лучше переименовать пакет в php5-fpm? А то, например, при смене админа — новый не сразу сообразить может, что стоит FPM, а не CGI.
Точно, так было бы правильнее. Но не нашли как по человечески решить проблему с тем, что поломаются зависимости, которые на php5-cgi привязаны. Если бы php5-cgi был в дебиане виртуальным пакетом, там бы и сделали. А в той ситуации, что есть сейчас, как решить не понятно. Идеи приветствуются!
Дык… Зависимости решаются по 2 пунктам из информации о deb-пакете: provides (какие возможности предоставляет пакет) и depends (от чего пакет зависит). Вам лишь нужно в пункте provides у php5-fpm прописать `phpapi-20060613+lfs` — php5-cgi предоставляет только это.
Точно ли сработает?

Смотрю зависимости, например, на phpmyadmin — там нет зависимостей от phpapi-20060613+lfs:
Package: phpmyadmin

Version: 4:2.11.8.1-5+lenny1
Depends: libapache2-mod-php5 | libapache-mod-php5 | php5-cgi | php5 | libapache2-mod-php4 | libapache-mod-php4 | php4 | php4-cgi, php5-mysql | php5-mysqli | php4-mysql, php5-mcrypt | php4-mcrypt, perl, debconf (>= 0.5) | debconf-2.0

о, я только модули смотрел :)
ну тогда 2 пункта в provides — phpapi и php5-cgi.
сам собирал пакет с provides phpapi — всякие php5-gd кушать не просили и не жаловались.
Ребят, кто прояснит вопрос: сделали ли в php-fpm apache-like управление воркерами? Видел мануал в сети, там в примере конфига юзается, а на официальном сайте в вики указано что только static в настоящее время работает. Кому верить?
сделали, в рассылке новость пару дней назад была.
и переименовали его, из apache_like в dynamic
Как обычно, с чем-нибудь возишься всю ночь, наконец заставляешь работать, заходишь на хабр и на главной расписано как твою задачу решить за 5 минут, причём решить грамотно, а не через… в общем как сам решил :)

/me пошёл сносить всё что намудрил за ночь
а можно конфигурацию php-fpm.conf оптимизированного пресета отдельно выложить?
Конфиг в deb-пакете отличается от пресетовского только юзером, от которого выполняются скрипты. Все остальное совпадает.
Да, хоть это не так востребованно, как под i386, но на следующей неделе выложим.
Спасибо, попробую его на праздниках. Пока в большинстве случаев самосборный стоит.
Господа, прошу прощения за вопрос не совсем по теме, я недостаточно хорошо разбираюсь в вопросе.

Вопрос к части с чего начинается статья, а именно «FastCGI. Обычно используется с nginx в проектах с высокими нагрузками»

Димтрий Котеров в статье dklab.ru/chicken/nablas/49.html утверждает, что это не совсем так. Я понимаю что по хорошему нужно поставить все самому и получить собственное мнение, просто это нужно делать.

С другой строны, читатели этой ветки, возможно, уже провели такие исследования и поделитесь даннми со мной?
Статья Дмитрия называется "… или почему FastCGI не ускоряет PHP", но кроме ускорения есть и другие параметры, например расходуемая память.
Спасибо.
По этой части у меня есть ясность. Именно поэтому, когда я цитировал автора топика, я не включил часть «или дефицитом ресурсов» :)
У экономного расхода памяти есть эффект — повышение производительности на единицу ресурса. Утрируя, на сервере с 8 Гб ОЗУ можно запустить тысячу процессов apache/mod_php из которых, скажем, только 100 будет выполнять php-скрипты (остальные отдавать статику) или несколько nginx + две тысячи php-fpm. Правда, две тысячи php-fpm трудно себе представить :)

Если nginx стоит фронтендом перед apache/mod_php или перед php-fpm/php-fastcgi, некоторый прирост в производительности все-таки будет у FastCGI за счет исключения лишней сборки/парсинга HTTP, которые будут между nginx и apache.
Спасибо. Теперь эта часть ясна. Как я понял, вы имели в виду общую производительность системе, в то время как у Котерова считаласть производительность только PHP части.

Думаю мне, нужно проводить тесты самостоятельно ;)
Ну опять начинается. :-) При чем тут php-fpm и расход памяти? У php-fpm он только чуть-чуть ниже, чем у apache_mod_php.

Экономию памяти дает не php-fpm, а а) срезание медленных клиентов nginx-ом, и — в меньшей степени — б) запрет отдачи статики тем же процессом, что уже отдал когда-то динамику и съел у системы память. Про (а) все понятно — nginx нужно в любом случае использовать, что для apache, что для php-fpm, ибо пользователи на модемах и сотовых телефонах не дремлют. Про (б) же — если мы поставили apache_mod_php+nginx и медленных клиентов уже нет (т.е. все запросы выполняются быстро — кстати, нужно еще буфера nginx-а настроить правильно), то чаще всего не так уж и важно НА ОБЩЕМ ФОНЕ, отдаем мы статику апачем или же напрямую nginx-ом (зато если через apache отдавать, это обычно проще конфигурировать).

В общем, для экономного расхода памяти настроить php-fpm+nginx проще, чем apache_mod_php+nginx. Но это вовсе не значит, что «php-fpm дает экономию памяти» (в режиме с не-apache-like воркерами это еще и не всегда так). Просто нужно настраивать все правильно и измерять результаты.

Лично я люблю использовать php-fpm+nginx, но главное соображение для меня — не экономия ресурсов (ее можно добиться в обоих случаях), а минимизация числа конфигов, которые нужно исправлять при интенсивной разработке (особенно в системах с множеством «виртуальных хостов»).
мне кажется, что все недопонимание оттого, что одни сравнивают nginx->apache+mod_php vs nginx->php-fpm, а другие — apache+mod_php vs nginx+php-fpm. :)

с другой стороны, nginx+php-fpm это банально более простое и гибкое решение. я конфиги апача с его реврайтами без головной боли даже вспоминать уже не могу. да и собирать апач для backend-only надо специально — слишком много лишнего. в общем, смысла нет.
> то чаще всего не так уж и важно НА ОБЩЕМ ФОНЕ, отдаем мы статику апачем или же напрямую nginx-ом (зато если через apache отдавать, это обычно проще конфигурировать).

Разница все-таки большая. Если отдавать апачем статику через nginx, то оверхед настолько большой, что производительность «с апачем» в крайних случаях меньше чистого nginx на порядок. Мелкий оверхед на дополнительный HTTP-сеанс не считаем, хотя это десятки процентов. Но фатальный удар по печени наносят временные файлы и буферы — полезное использование памяти сокращается в разы.

Когда nginx отдает статику сам, путь от данных на диске к клиенту выглядит так: диск -> буфер (ядро) в памяти -> ядро через sendfile отдает данные из дискового буфера клиенту без отдельного tcp буфера.

Когда nginx отдает статику через апач, путь намного тяжелее: диск -> буфер (ядро) в памяти -> ядро через sendfile отдает в буфер чтения tcp ядра -> nginx читает из tcp-буфера в свой буфер -> nginx из своего буфера пишем в временный файл -> ядро выделяет дисковый буфер для временного файла -> если данные отдаются долго, они сбрасываются на диск, и потом читаются по-новой -> ядро через sendfile отдает данные из дискового буфера клиенту без отдельного tcp-буфера.

Основные потери памяти во втором случае приходятся на временные файлы nginx. А временный файлы, сброшенные на диск, еще и замедляют всю работу дополнительным дисковым IO.
ага. ну еще большая разница какой размер файла (влазит ли в буферы)

был какой то сторонний модуль для апача, который ставится последним в цеплочке, и смотрит: если ни один фильтр не был применен — отдает x-accel-redirect :)

впрочем если не хайлоад и из статики логотип с css-ом, на это все обычно можно забить )
подскажите где забрать пакеты для ubuntu 9.10. По ссылке 404 отдает.
Что-то у них поломалось. Нужно открыть адрес https://launchpad.net/~ubuntu-security/+archive/ppa/+build/1367031 и там внизу под заголовком Built files все .deb-файлы из комплекта.
Сделал апдейт к топику.
php-fpm там отсутствует. И версии немного не сходятся:
php5-common_5.2.10.dfsg.1-2ubuntu3~pre2_i386.deb — это заявлено в топике
php5-common_5.2.10.dfsg.1-2ubuntu6.3_i386.deb — это лежит по ссылке.

Я в недоумении… Что качать-то?:))
дали на тест сервер за что большое спасибо
скопировал свой сайт ipod-touch-max.ru/ wordpress с кучей плагинов
все завелось без проблем правда не работает ЧПУ на ворпресс, не стал копать nginx
для формировании главной страницы 72 запросов к MySQL
без нагрузки 0.900 сек.
с нагрузкой 50 соединений 10 сек

loadimpact.com/result/94.127.66.32-6fc2e1d7035d8eb2cae992848701a91e

вот так все выглядит в идл

top — 21:41:25 up 9:45, 3 users, load average: 0.01, 0.84, 0.99
Tasks: 53 total, 1 running, 52 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 262340k total, 251056k used, 11284k free, 10632k buffers
Swap: 131064k total, 448k used, 130616k free, 114200k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 2116 688 588 S 0.0 0.3 0:00.34 init
2 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 15 -5 0 0 0 S 0.0 0.0 0:00.06 ksoftirqd/0
5 root RT -5 0 0 0 S 0.0 0.0 0:00.18 watchdog/0
6 root 15 -5 0 0 0 S 0.0 0.0 0:00.52 events/0
7 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
19 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 xenwatch
20 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 xenbus
48 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kblockd/0
58 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kseriod
89 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush
90 root 20 0 0 0 0 S 0.0 0.0 0:00.34 pdflush
91 root 15 -5 0 0 0 S 0.0 0.0 0:00.06 kswapd0
92 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 aio/0
215 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 net_accel/0
507 root 15 -5 0 0 0 S 0.0 0.0 0:00.24 kjournald
584 root 16 -4 2304 760 480 S 0.0 0.3 0:00.26 udevd
935 root 15 -5 0 0 0 S 0.0 0.0 0:00.00 kjournald
1083 root 20 0 27288 1312 948 S 0.0 0.5 0:00.03 rsyslogd
1103 root 20 0 5432 1020 668 S 0.0 0.4 0:00.00 sshd
1146 root 20 0 2848 1312 1080 S 0.0 0.5 0:00.00 mysqld_safe
1185 mysql 20 0 160m 58m 5316 S 0.0 22.7 3:48.65 mysqld
1187 root 20 0 1764 544 472 S 0.0 0.2 0:00.00 logger
1249 nobody 20 0 2596 1076 648 S 0.0 0.4 0:00.54 memcached
1268 root 20 0 4860 688 276 S 0.0 0.3 0:00.00 nginx
1269 webmaste 20 0 5060 1612 868 S 0.0 0.6 0:00.64 nginx
1270 webmaste 20 0 5364 1876 860 S 0.0 0.7 0:02.04 nginx
1283 root 20 0 70308 4228 1464 S 0.0 1.6 0:02.48 php-cgi
1284 webmaste 20 0 74692 19m 12m S 0.0 7.5 1:36.11 php-cgi
1285 webmaste 20 0 74692 18m 10m S 0.0 7.1 1:35.37 php-cgi
1286 webmaste 20 0 74692 18m 11m S 0.0 7.3 1:34.36 php-cgi
1287 webmaste 20 0 84136 31m 15m S 0.0 12.4 1:37.69 php-cgi
1288 webmaste 20 0 74716 19m 11m S 0.0 7.5 1:36.10 php-cgi
1350 root 20 0 5640 1816 1472 S 0.0 0.7 0:00.06 master
1358 postfix 20 0 5696 1760 1432 S 0.0 0.7 0:00.00 qmgr
1369 root 20 0 3792 968 760 S 0.0 0.4 0:00.00 vsftpd
1375 ntp 20 0 4276 1284 1004 S 0.0 0.5 0:00.94 ntpd
1395 root 20 0 5172 984 800 S 0.0 0.4 0:00.04 cron
1413 root 20 0 1780 508 440 S 0.0 0.2 0:00.00 getty
1743 postfix 20 0 6020 2588 1904 S 0.0 1.0 0:00.00 tlsmgr
1863 root 20 0 8328 2736 2240 S 0.0 1.0 0:00.78 sshd
1865 root 20 0 5900 1616 1300 S 0.0 0.6 0:00.00 bash
1949 postfix 20 0 5652 1720 1396 S 0.0 0.7 0:00.00 pickup
1954 root 20 0 2408 1108 884 R 0.0 0.4 0:03.02 top
1967 root 20 0 8984 3528 2240 S 0.0 1.3 0:04.42 sshd
1969 root 20 0 5900 1612 1296 S 0.0 0.6 0:00.00 bash
1973 root 20 0 8176 2724 2236 S 0.0 1.0 0:00.04 sshd
1977 root 20 0 5900 1604 1296 S 0.0 0.6 0:00.00 bash
1985 root 20 0 8324 2692 2208 S 0.0 1.0 0:00.02 sshd
1987 root 20 0 4860 1492 1132 S 0.0 0.6 0:00.00 sftp-server
1988 root 20 0 8176 2668 2208 S 0.0 1.0 0:00.02 sshd
1990 root 20 0 5868 1436 1192 S 0.0 0.5 0:00.00 bash

Зря не указываете версию fpm. В 0.6 есть несколько нерешенных еще проблем, продакшен качество пока только у 0.5.

Дримкетовские это точно 0.6 причем не самый новый.
Кажись нашел багу.

Поставил у себя (php5-cgi, php5-mysql, php5-gd) на рабочий проект — отвалился mysql (Fatal error… undefined function mysql_connect ...)
С перепугу откатился на родной.

Позже обнаружил что php пытается читать additional конфиги из /etc/php5/cgi/conf.d
А на самом деле они сложены в /etc/php5/conf.d, и в родном php5-cgi есть симлинк /etc/php5/cgi/conf.d -> /etc/php5/conf.d

Видимо про симлинк таки забыли…

не могу собрать с этого мануала. я так понял вышли пару securuty фиксов и тянется все равно все с security.debian.org
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 September 2008

Location

Россия

Employees

2–10 employees

Registered

24 June 2009