Comments 117
Все конечно отлично, но мало того что инструкция step-by-step, так еще и не видно где и что мы выигрываем в производительности.
Ну и хотелось бы тестов на одних и тех же данных до и после.
Думаю сделать отдельную статью на тему оценки производительности php-fpm+nginx+mariadb vs apache2+mod_php+mysql5.5
У нас используется заббикс по умолчанию, все пакеты из стандартных реп CentOS + EPEL.
Количество данных не очень большое

полет нормальный, кроме некоторых проверок по snmp некоторых устройств, виснут проверки и так и висят в очереди.
Очень может зависеть от шаблонов. Особенно там, где шаблоны охватывают более общие параметры, которых может не быть в частных конфигурациях клиентов. Так что зачастую совсем не проблема.
А потом придет большой и страшный postgresql и скинет мускуль с пьедестала. Собственно, я не похоливарить хочу, у меня был zabbix на ~15k устройств, у нас ушло под пару сотен человеко-часов на оптимизацию мускуля, и ~15 человеко-часов на переезд на постгрес, настройку failover и выпуск в продакшн. После чего (уже без меня) количество устройств выросло примерно вдвое, но все крутится на том же железе и справляется с нагрузкой с запасом.
Довольно таки странно.
Даже на форумах заббикса очень многие уходит от постгреса, т.к. он медленнее оказывает чем мускул.
Не ради холивара.
Любопытно, и странно.
В то время мы видели выход в вертикальном масштабировании системы и попробовали postgresql ради чистоты совести, потому что была свободна аналогичная железная конфигурация.
В рамках нашей базы данных для заббикса, мы уже стояли на грани граблей шардинга (база была >500Гб), обновление или перезагрузка мускуля (все было в innodb, двигло percona 5.1) выливалась в 10-20 минут простоя, что не допустимо. Ну и, соответственно, качество работы failover в мускуле, да еще и с шардингом — это весело! Также у сервака заббикса росли очереди на запись данных в БД, чтение данных для аналитики было, мягко говоря не быстрым. После перехода на постгрес (причем тюнили, по началу, каким-то перловым скриптом из поставки), у нас пропала потребность шардить, очередь на запись в БД не превышала дельты времени в минуту (при мускуле до 8-10 минут доходило, кроме анализа tmp-данных, мы делали тесты на простом пинге, и смотрели, когда придет уведомление), чтение данных для уведомлений, графиков стало, если не быстрым, то приемлемым.

PS Железка для БД была, что-то вроде HP BL460g5 (или g6), с двумя топовыми (на момент покупки 2011 год) камнями, памяти было 32Гб. Все это дело стучалось по оптике(SAN) в слабонагруженную полку с 15К SAS дисками, собранными в raid 1+0.

PPS ребята с той компании прислали информацию: сейчас примерно 32k устройств (компы/сервера, софт, сетевые девайсы), база ~1,2 Тб, живут на том же блейде, у БД две головы master-slave, pgpool. Довольны, критичных тормозов не замечено.
Ну, к примеру, между 5.1 и 5.6 существенные изменения в производительности, в лучшую сторону.
Все относительно. :) Сейчас у меня percona 5.6 для веб-проекта, но я активно лоббирую переход на postgresql. А тогда, был или секс с оптимизацией и шардингом мускуля (percona 5.1), или posgresql 9.1.

Исходя из текущего опыта работы, для базы больше 10 Гб я постараюсь изначально заложить posgresql (и лучше работает с большими объемами, и лучше failover, и master-master с меньшими потерями производительности).
и master-master с меньшими потерями производительности

А можно тут поподробнее? Интересует как ныне обстоят с этим дела? Потому как погуглив по интернетам для кластеризации pg находится парочка невнятных сторонних костылей, не более того. Или я что-то пропустил? Какие есть родные средства для multi-master HA кластера?
Я краем глаза смотрел на ЭТО, и я сравнивал с percona master-master который у меня тогда работал. Знакомцы у меня на Slony работают и не жалуются.

Там в конце выводы:
— PostgreSQL и MySQL имеют почти одинаковую производительность.
— Важно настроить базы на производительность.
— MySQL адекватней расходует цпу чем PostgreSQL. (PostgreSQL поддерживает внешние ключи в партициях)
— PostgreSQL более стабилен в проблемных ситуациях с IO.

И где тут что-то плохо пишут про PostgreSQL? Как по мне он отлично справляется, кое где хуже, кое где лучше MySQL.
Отличная статья, не так давно мне ее очень не хватало. Но по ряду причин, и слава богу, я избавился от zabbix в своем курятнике :)
У меня сейчас нет сетевого железа для мониторинга, но нужно мониторить много софта. Поэтому путем проб и ошибок остановились на munin+monit. Возможно добавлю nagios/icinga.
Спасибо за статью. Справедливости ради стоит отметить, что разницы по производительности между правильно настроенными Apache и Nginx не видно даже на маломощных атомах. Что касается PostgreSQL vs MySQL (MariaDB), то мой опыт говорит о том что тут нет победителя, всё зависит от наших знаний и умения эффективно настроить ту или иную базу данных. Что точно будет медленне — Oracle.
Есть существенная разница в производительности между php-fpm и mod_php
Кроме того, при большом количество онлайн, nginx с php-pfm будет расходовать ОЗУ гораздо экономичней
Согласен что он прекрасно дружит с apache и я использую его всегда в этой связке, где мне нужен mod_rewrite и htaccess
но в данном случае он совсем не нужен.

Цитата:
apache на каждого клиента создает отдельный процесс или поток, на выбор. Это создает проблемы в случае клиентов с медленными каналами, когда создаются дофига процессов/потоков, которые по факту ничего не делают, только память отжирают. Nginx использует более совершеный способ работы с сетью, когда один поток может работать с несколькими соединениями, плюс в периоды с вот такими медленными клиентами он просто спит, используя процессор по минимуму. Была хорошая статья, забыл, где, ну вот хотя бы такая www.slashroot.in/how-is-nginx-different-from-apache
Это актуально, когда много-много пользователей (тысячи и десятки тысяч). В случае с zabbix не требуется.
Все познается в сравнении, на самом деле! я думаю что nginx лучше для этой задачи чем apache2
В данном случае нет ни одной объективной причины упражняться с нештатными (для zabbix) конфигурациями nginx+php-fpm, вместо дефолтных apache+mod_php. Ну, кроме как поупражняться для тренировки.
Делая свой выбор я руководствовался не только личным опытом но и статьям подобным этой
blog.michaelfmcnamara.com/2012/11/apache2-mod_php-vs-nginx-php-fpm/
из собственного опыта скажу, страница overview.php например, в конфигурации приведенной выше, открывается примерное в 2 раза быстрее чем при работе на apache2 + mod_php
Если сравнивать работу php-fpm под nginx и apache2, то к контексте работы с zabbix, у последнего нет ни одного преимущества.
Мне сложно судить о том чья статья адекватнее, все сказанное основывается на моих собственных наблюдениях,
впрочем, статья 2008 года про php 5.2 не вызывает у меня никакой уверенности
Ну ок, если в этой статье ты увидел только версию php, а не базовые принципы, то дальнейший разговор смысла не имеет.
Что-то сплошной оффтопик идет. Какая нафиг разница: apache+mod_php или nginx+fastcgi?! У вас что, клиентами морды zabbix сидят 300-400 человек сразу?

Вариант nginx+fastcgi скорее всего изначально будет настраивать человек, который понимает, что он делает. А остальные 90% вполне будут довольны апачем. Какой вообще смысл у вебморды системы мониторинга смотреть на ее производительность? Надо смотреть на производительность БД и каналов.
Согласен в большинстве случаев, но на очень тяжелых страницах вроде overview.php для всех устройств в zabbix, разница очень ощутима
Опять же, ИМХО, тут основная проблема в скорости работы БД, и потом уже настройки представления данных. И разница будет заметна, в первую очередь, при обилии клиентов на системе. Для одного-двух пользователей разницы большой быть не должно. Ну уже проверено это много раз. :)
У меня сейчас в среднем 25-30 пользователей онлайн, через пару месяцев это число должно увеличиться вдвое
Что вы делаете такое с zabbix`ом, что столько народу нужно туда пускать единовременно? У меня самый навороченный юзкейз был на 20 человек в 10 городах. И то при разделении прав, они у меня видели только то, что им нужно.
Посмотри в сторону разделения областей видимости у пользователей. Я при >15k устройств (железо и ПО и сеть) не имел больших проблем с отображением и тормозами. У меня основной интерфейс крутила на nginx+fastcgi, а тестовый на апаче с mod_php. Ни там ни там я большой разницы не замечал.
Меня немного посетило удивление, обычно при таких объемах сидят на чем-то коммерческом, дорогом и красивом, типа Tivoli.
У нас около 7000 устройств в сети, пока что добавляем по мере необходимости
У нас очень много сетевого оборудования отправляет snmp и есть фермы серверов на которых много дисков, по ним собираются все данные по iostat
Так или иначе, nginx+php-fpm+mariadb работает нормально для меня, но скоро мы переезжаем на haproxy+percona вместо mariadb
Межу маришкой и перконой существенной разницы я не заметил (веб-проект, ~100 человек одновременно + статистика там же). Большого смысла менять nginx на haproxy я не вижу.
haproxy для балансировки запросов на percona,
percona для масштабирования и отказоустойчивости,
nginx отсанется на месте…
вообще вот статья про haproxy habrahabr.ru/post/198448/
я понял, подумал, что haproxy для проксирования на fastcgi. Percona в master-master на галере?
Да это будет percona xtradb cluster в multi-master, но через балансировщик haproxy
Сочувствую, у меня на продакшене одно время жило такое решение.
Ощутимое падение скорости записи, даже при условии, что серваки в одном гигабитном свиче или на виртуалки на одной железке (а тут яйца все в одной корзине). Падение одного из серверов может обрушить весь кластер (проходил в конфигурации кольца на 4 и на 5 машин). При записи на несколько нод одновременно, падение скорости вставки и чтения еще заметнее. Географически распределенный вариант не реален в принципе, если только есть своя оптика между датацентрами.

Для меня этот опыт послужил определяющим для перехода н postgresql+pgpool.

PS это при объемах записи куда меньших чем заббикс на 200 устройств.
Мы замеряли производительность подобных решений, кроме того, подобное решение обслуживает все наши web фермы
вот результаты тестирования производительности кластера в режиме записи и чтения в multi-master через haproxy

[root@rs-haproxy ~]# sysbench --num-threads=1000 --max-requests=100000
--test=/usr/share/doc/sysbench/tests/db/oltp.lua
--mysql-table-engine=innodb --db-driver=mysql --mysql-db=test
--oltp-table-size=2000000 --oltp-test-mode=complex --mysql-engine-trx=yes
--oltp-auto-inc=off --mysql-user=tester --mysql-password=tester
--mysql-host='10.100.100.245' run
sysbench 0.5: multi-threaded system evaluation benchmark

Running the test with following options:
Number of threads: 1000
Random number generator seed is 0 and will be ignored

Threads started!

OLTP test statistics:
queries performed:
read: 1400140
write: 400040
other: 200020
total: 2000200
transactions: 100010 (614.25 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 1800180 (11056.55 per sec.)
other operations: 200020 (1228.51 per sec.)

General statistics:
total time: 162.8157s
total number of events: 100010
total time taken by event execution: 162356.5746s
response time:
min: 45.35ms
avg: 1623.40ms
max: 6853.35ms
approx. 95 percentile: 2490.94ms

Threads fairness:
events (avg/stddev): 100.0100/1.02
execution time (avg/stddev): 162.3566/0.65

Для поддержания кворума, у нас есть несколько арбитраторов garbd
Я проводил у себя похожее тестрование, сейчас пишу по памяти:
чистая перкона ~ 1000 транзакий/сек
кластер master-master 4 машины (без арбитров) ~ 400 транз/сек
postgresql (master-slave+pgpool) ~ 1500 транз/сек

Для нас основная не MS субд — mysql, больше реданденси мы добиваемся на multi-master percona
да это медленее при вставках, да это рассинхрон транзакций
но это реданденси и маштабированость
Какое крутое исследование, даже конфиги не показаны. Заслуживает доверия, безусловно.
Конфиги чего? Как кластер перконы на галере собирать? Или может просто вчитаться в документацию, где написано: что транзакция является закрытой после ее выполнения на всех узлах кластера.

Чтение конфигов тут что-то изменит?
Попробуй читать ссылки, перед тем как их постить.
Перефразирую — nginx хорошо масштабируется. Это и призваны показать тесты с бенчмарками в сотни/тысячи запросов в секунду и с сотнями/тысячами тестовых ботов.
Они это и показывают.
Я же тебе пытаюсь объяснить, что при 10-20-50-100 пользователях и 5-10-20 запросов в секунду никакой разницы между apache+mod_php/apache+php-fpm/nginx+php-fpm не будет. При условии, что все настройки во всех случаях сделаны правильно, это всяким горе-блоготестерам редко под силу, максимум могут накатить все по дефолту и ab/httperf освоить.
Ведь, млин, код выполняет все тот же php во всех этих вариантах, ему похрен, кто его спавнит. Та же субд в бекенде.
php-fpm расходует меньше памяти и работает быстрее на тяжелых php страницах вроде
overview.php, да большую часть задержки будет на работу БД, но генерация страницы это огромная работа
Например, наш overview для всех хостов и данных, создает html страницу объемом 50МБ!
Ее генерация требует более 1ГБ памяти и на mod_php это генерируется в 2 раза медленее
Это вполне конкретные цифры, речь не идет о коне в вакуме
мы используем APC для кеширования опкода
по ссылке я читал, меня hello world на php не убедил
я повторяюсь
сравнивал в реальных условиях сам, при работе с zabbix и для хостинга сайтов
Да
а как вы хотели то, нативный модуль апача или же внешний fastcgi
мы тут на 100 сообщений уже об этом спорим
я поддерживаю идею что php-fpm быстрее
Глупая идея, думаю нагуглить сравнение скорости не сложно.
Как минимум присутствует сетевой оверхед tcpip для обращения к fastcgi, которого в mod_php нет.
Или вы думаете что fastcgi ставят потому что он быстрее, а не меньше памяти жрет?
Что вы поддерживаете то?
Что php-fpm больше оверхед чем у mod_php?
А кто говорит что большой, просто он есть и будет все работать дольше.
Ну посмотрел, нигде не увидел, что накладные расходы на fastcgi стали вдруг меньше чем родной нативный mod_php
Вот вам старый обзор для пруфа
www.pentarh.com/wp/2008/07/11/test-results-apache-vs-php-fcgi/
Мне кажется спор и яйца не стоит, ну есть оверхед в fastcgi и никуда от этого не деться.
Оверхед mod_php в том, что он работает в пространстве апача, который очень любит треадится, и основной расход идет не на взаимодействие с сокетом или tcp, а на переключение контекста, расход памяти и организацию новых тредов. Тут уже сугубо вопрос архитектуры.

Говоря по другому: пришел клиент, делается новый поток в апаче, который загружает в свой поток(и) mod_php, который потом загружает бинарник/либы, и потом в них выполняет код. Так как я глубоко тут не копал, у меня больше вопросов, чем ответов. Я не люблю пых и нигде его не использую. Но у меня есть проект на django, и мы пробовали и mod_python, и mod_wsgi, все равно ушли к варианту nginx+gunicorn, который, грубо говоря, аналогичен nginx+fastсgi мира php.
Выбрали из-за скорости обработки клиентских запросов, загрузки памяти и IO при этом. На проц плевать, было… почти.
за счет исполнения кода php в конвеере php- fpm, код для всех запросов в момент времени исполняется быстрее и с меньшими накладными расходами, плюс
* Управление процессами. Возможность «плавно» останавливать и перезапускать php воркеры без потери запросов. Возможность плавно обновлять конфигурацию и binary без потери запросов;
* Ограничение ip адресов, с которых могут приходить запросы от web сервера;
* Динамическое количество процессов, в зависимости от нагрузки (TODO);
* Запуск воркеров с разными uid/gid/chroot/environment и разными php.ini опциями;
* Логирование stdout & stderr рабочих процессов;
* Аварийный перезапуск всех процессов при случайном разрушении shared memory opcode cache, если используется акселератор;
* Принудительное завершение подвисших процессов, если set_time_limit() не срабатывает (TODO);
Вот подтвердите хоть чем нибудь
за счет исполнения кода php в конвеере php- fpm, код для всех запросов в момент времени исполняется быстрее
или откуда вы это взяли?
Что за конвеер php-fpm?
Что за момент времени?
Выше я вам дал пруф где показано что столько то запросов апач выполнил быстрее, а php-fpm медленнее.
Вот вам статья 2013 года
phptime.ru/php-performance/perevod-pochemu-fastcgi-nginx-bystree-chem-apache-mod_php.html
я сегодня видел уже эту статью, она совершенно не внушает доверия
Ну замечания по обоим статьям:

1. «Если его нагрузить статикой, все будет намного хуже. » — то есть тест уже не реален. Смысл-то в том, что nginx проксирование и статика, а fastcgi-динамический контент. Можно сказать, что перед апачем мы поставим nginx: но вы часто видели такие решения?
2. «Для тестирования я сделал простенький скрипт «привет, мир». Почему такой простой? Потому что когда вы работаете с интерпретатором PHP, не должно быть никакой разницы в производительности. Тогда почему не сделать пустую страницу? Потому что для чистоты эксперимента необходимо обеспечить двустороннюю связь. Моей целью было проверить пропускную способность веб-сервера, а не PHP. Так что я потратил минимум времени на PHP и все внимание уделил проверке передачи данных.» — не, ну отличная синтетика!!! Респект и уважуха. Это как у меня в зале, приходит человек, весь из себя качек-кросавчик, и жмет в становой 100кг на пару раз, и прихожу я, весь из себя увалень, и жму 200 кг на раз, а соточку на десяточек.
3. все тесты исходят из того, что апач — это только слой для запуска php.

Теперь оттолкнемся от реалий, в текущей задаче стоит вопрос реального приложения, где апач будет отдавать статику, а не служить прослойкой для запуска php. Соответственно, если мы возьмем nginx(+статика)+fastcgi, и апач(+статика)+mod_php, то производительность и расход памяти связки nginx+fastcgi останется на том же уровне, а апач будет куда ниже. И разговор о CDN тут будет не уместен, так как это все равно, что поставить nginx перед апачем.
Так никто и не спорит про статику, там проще уж свой написать сервер, чтобы чисто статику умел и все, будет быстрее nginx
Извини, конечно, но ты жжешшшь!!! :)))))

Понятное дело, что ПО, которое должно угодить всем, будет не так шикарно, как разработанное под одну, конкретную, задачу. Но, опять же, о реалиях: вы часто встречали такое? Разница между nginx или lighthttpd сильно велика? сравним redis и tarantool?
Просто разговор был про скорость php.
Ну знавал я серверы, которые статику быстрее nginx отдавали, даже у яндекса такой есть.
Ну так если рассуждать то и php-fpm статику отдавать не умеет, не говоря уже о производительности при отдаче статики.
В реальных проектах никто статику не отдает через php, она лежит на каком нибудь отдельном сервере и прекрасно отдается другим вебсервером.
Надеюсь все таки вы поняли, что php выполняется быстрее в mod_php
Еще раз повторю вопрос: Вам важно академическое исследование?
Тогда нужно вообще мерить чистый fastcgi, так как он не выполняется в пространстве nginx, в отличии от mod_php. Или Вам важно понимать как и что работает на реальных проектах?
Я люблю реалии, вот вы в состоянии взять и написать сервер для того, что бы ваша система работала быстрее? или же вы сосредоточитесь на реализации функционала, который позволит вам зарабатывать?

Вот когда уровень вашего проекта дойдет до N-датацентров и M-серверов, когда вы на текущих решениях начнете затыкаться, тогда можно начинать говорить о написании своего сервера.

И соответственно: связка nginx+fastcgi быстрее в реальном применении, и тем более, когда много клиентов. Чем апач+mod_php похвастаться не может. А вот в синтетическом тесте с подогнанными условиями он выигрывает, и то максимум на 20%, что нивелируется тем, что тест синтетический.
Ох я сделал в этой жизни один крупный проект с 6 датацентрами и большим количеством серверов. и трафиком несколько десятков гигабит.
Или скажем у меня есть клиент у которого мобильная реклама на 10 000 000 показов в день.
Трудно попрекнуть успешного фрилансера большими проектами, да с вконтактами, фейсбуками и гуглами пока не работал, в яндекс в свое время тоже не взяли(кстати козлы 8)).
Ты все 6 датацентров сам собирал, как фрилансер? Подбирал серваки, архитектура, инфраструктура, монитинг, оборудование? То есть дела все один и сам?
Извини мое недоверие, я прекрасно разбираюсь, что такое сделать датацентр, что такое его сертификация, оборудование, цели, отказоустойчиваость. Я прекрасно разбираюсь в построении систем на обслуживание не 10 000 000 показов, а 10 000 000 клиентов приходящих на ресурс в день. И как минимум для того, что бы начать писать свое системное ПО, отдача от ресурса должна быть в ТАКОМ плюсе, что IPO будет скромно стучатся в двери.

Самый просто пример у нас сейчас: мы используем rabbitmq, есть вещи в нем, которые нас не устраивают. Есть zeromq, который крут, но требует всю обвязку писать вокруг себя. У нас есть ресурс на это дело (мозги, опыт), но написание такой системы будет стоит, скажем, 2000 человеко-часов, что примерно ~1 400 000 рублей (при стоимости внятного программиста в 150 000р в мес), еще сюда надо заложить багфиксинг, развитие и тд.

От сюда моя мораль: я согласен с тем, что в «идеальном газе» (помните такое термин из школьного курса физики?! :) apache+mod_php дает 15-20% (судя по статьям) прирост, но в реальности и в мультиклиентской среде его отставание будет огромно.
Его отставание будет только в памяти, даже в реальных условиях, а про статику мы же знаем, что она всегда отдельно лежит в нормальных реальных условиях, говносайты не учитываем.
Вы второй кто дает эту статью 2008 года из жизни php 5.2  в этом треде
Версия php она как бы не влияет на оверхед в тестах то юзается одна и таже.
Ну так стек tcp-ip не изменился
да и как бы php-fpm не менялся сам то php один и тот же
за счет чего он по вашему должен быть быстрее?
Ну назовите хоть одну причину почему он должен быть быстрее, возьмите например за аксиому, что php одинаковой версии выполняется одинаково быстро.
Вообще заббикс завелся на nginx + php-fpm из коробки за полминуты, даже никаких плясок не надо было.
В статье есть достаточно важная ошибка. Базу надо создавать следующим образом: CREATE DATABASE zabbix CHARACTER SET utf8 COLLATE utf8_bin;

Без добавления utf8_bin база данных будет не регистрозависимой, тогда как Zabbix является регистрозависимым приложением.
Ну скажем, это уже трудно назвать nginx-ом после этого. Для справки, в nginx примерно 120 тыс. строк кода на Си, а в Хромиуме только лишь на C++ 3.5 млн., конечно не совсем корректно сравнивать, не весь хромиум используется в PageSpeed, но так, для понимания.

Ходил тут недавно человек, удивлялся, почему у него nginx выдает всего 20rps, оказалось надо PageSpeed отключить, чтобы было на несколько порядков больше.

Про стабильность я уж умолчу.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

4 December 2003

Location

Сингапур

Employees

1,001–5,000 employees

Registered

9 August 2008

Habr blog