Pull to refresh

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 уже не заставить из пакетов устанавливать. Но вам, за вашу работу большой РЕСПЕКТ!
к 5.3 пока к сожалению много чего еще нет, к примеру того же ZendOptimizer-а
Когда планируется добавить в репозитари версию для 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 раза меньше теперь =)
а были попытки подружить PHP-FPM с xcache?
Да, с xcache работает нормально.
Ждем оптимизированный.
А так все равно акселератор билдить.
В репозитории есть 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-пакете отличается от пресетовского только юзером, от которого выполняются скрипты. Все остальное совпадает.
как я понимаю нуэно обновлять это вместе с пхп?
все так?
Скажите, а версию amd64 не собираетесь выкладывать?
Да, хоть это не так востребованно, как под 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
Sign up to leave a comment.