Падение сервера при высокой нагрузке

Тестов нет, но есть десятки клиентов, и сотни серверов, на которых всё наблюдалось и настраивалось. Я говорю основываясь именно на практическом опыте, а не на тестах. Тесты тоже делались и много. Даже HP как-то тестировали на нагрузку систему, которую я настраивал :) Но очень давно, и результатов их, конечно, нет под рукой.

Зато есть кейс по оптимизации VPS под нагрузку, в котором очень наглядно и отчетливо видно, что происходит с использованием ресурсов сервера после переключения в режим nginx+php-fpm:

Вот еще график, клиент прислал, дорвейщик.

Вот, дорвейщикам, кстати, очень помогает это. Среди клиентов есть ребята. У них обычно мощные дедики, с сотнями сайтов и парсерами. После подобной оптимизации сервак "дышать" начинает.

Поэтому, тесты тестами, а апач НЕ НУЖЕН ☝

Возможно для разработки хорошо, удобно - поставил и оно работает.

Но там где нагрузки... да скажите мне, нахрена фейсбук пилил свой HHVM, если апач настолько хорош?

UPD

Да ладно? Это какие же тяжелые процессы на себя берет nginx, если он не может обрабатывать php? Nginx берет на себя статику, а апач все так же продолжает пыхтеть под обработкой php, как и без него.

Да как вам угодно) Я вижу результаты. И просто показываю графики. Апач работает очень туго, по сравнению с php-fpm.

Вы путаете теплое с мягким. Апач выполняет скрипт и отдает результат. А вот fpm только выполняет скрипт, а результат отдает уже nginx.

И именно за счет того, что результат отдает не тяжелый процесс апача, а легкий nginx - и достигается значительная экономия памяти вэб сервера. Что уменьшает возможный своп, а следовательно и дисковую нагрузку вкупе с процессорной.

Вообще то это совершенно две разные вещи. Одно вэб сервер, а другое виртуальная машина для выполнения пхп кода. У них совершенно разное назначение.

Stek, это бесполезно. Просто redeyer свято верит в php-fpm, оставьте его в покое.

самая быстрая связка - без PHP.

Если есть разница между DSO и FPM, причем - разительная, значит проблема не в методе запуска PHP, а в чем то еще.

Мне под две задачи.

1. Уже работающее интернет радио https://user.radioboss.fm:2199/start/radio272/ перенести на свой VPS, сейчас оно на специальном стрим хостинге. Для этих целей поставил у себя сервер вещания ShoutCast +язык Liquidsoap + на них cms Centovacast.

В день 500 слушателей, продолжительность слушания в среднем 40 минут, поэтому одновременно подключенных в будни 50 слушателей стабильно, но с этой задачей работает сервер Shoutcast, он не жрет ресурсы, но скоро протестирую, посмотрю как будет.

Впрочем-то для этих целей требуется гарантированный 100 мб/с без лимитов, потому что у меня прицепляется по 200 ботов-риперов, они могут 6 тб в месяц накрутить + реальные слушатели 4 тб.

А таких провайдеров в России трудно найти, чтобы VPS был гарантирован 100мб, поэтому легкости перехода с одного провайдера на другой отсутствует.

2. Сделать сообщество dj, которое крутилось бы вокруг радио, там бы понаадобилась cms joomla/wp+форум phpbb.

Поэтому я тестирую на максимальные нагрузки во всем.

Их нигде не найти. Потому что впс использует порт физической машины, которая подключена к сети на скорости 100, 1000 или 10000 мбит. И если на физической машине 10 впс - делите порт на 10, а если 100, то на 100. Вспомним, что речь идёт о гарантированной скорости.

Исключения редки (это специальные решения, которые уже по сути не впс, а микроклауды какие-нибудь подключенные напрямую к свичу на соответствующей скорости). По сути физический сервер нужен при таких требованиях, причём не из дешевых атомов.

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

Я не спорю, можно и апач настроить чтоб работало нормально. Так можно и осла разогнать до 100 км/ч. Вопрос только один - зачем, если можно сесть в авто?) Чтобы держать такие нагрузки, как выше я показал на графиках (100 юзеров в секунду) - понадобятся мощные дедики с кучей ядер и десятками Gb RAM. А эта связка спокойно выдерживает подобное на минимальном VPS за 5 баксов :)

Вот именно в этом и недостаток апача. Он может все, но делает это хуже и с большими затратами ресурсов, чем узко-заточенные решения вроде HHVM или того же php-fpm.

Это так :) Но это не фанатичность, а прагматизм. Просто берем и юзаем. Там работает так. Тут сяк. Тут не надо никакой веры, все очевидно.

Не понимаю почему люди спорят с наглядными и очевидными фактами, взятыми из практики :) Покажите мне обратное, что апач держит лучше :) Зачем все эти притянутые за уши рассуждения о теплом и мягком ?)

А то темы начинаются с того что апач не держит, а как начинаешь говорить где выход - так сразу активизируются холиварщики что апач это вообще едва ли не лучшее, что случалось в IT )

Мой вам совет - запускайте проекты и решайте вопросы по мере их поступления :) Пойдет реальная нагрузка - тогда и надо искать решения и оптимизировать.

Угу. Просто берем и крестимся/камлаем/плюем через левое плечо. А чо? Работает же, никакой веры (на самом деле нет).

Ваша вера заключена в том, что вы утверждаете, что сервер стал работать лучше в разы чисто из-за перехода с apache+nginx на php-fpm+nginx. При этом у вас даже нет верифицируемости, а один субъективизм.

Сами себе придумали, что у апача тяжелые процессы, сами себя убедили в том, что php-fpm - панацея. А проблема может быть например в кривых запросах к mysql, где понатыкали select join distinct group by, который не оптимизируется а нуждается в полной замене + замене в коде. Оперативка кончается - начинаются проблемы из-за временных таблиц, которые пишутся в своп.

Ставите php-fpm и получаете экономию по памяти допустим 5%. Этого хватает, чтоб временные таблицы снова писались в оперативку на какое-то время и радуетесь:

- Ура! Производительность выросла в разы! Целебный php-fpm спас жизнь тяжело больного сервера!

Хотя у вас был просто временный эффект от высвобождения оперативки.

Просто попробуйте, зачем писать ерунду про 5% и кривые запросы под видом эксперта) Стандартные cms типа wp у десятков клиентов и на собственных серверах, сетки сайтов на известных CMS типа dle, wp. Rакие кривые запросы?) И нестандартные тоже - парсеры, самописные системы. Везде есть этот выигрыш в производительности и готовность к нагрузке. И не на 5%, а в 3-5 раз. Не временный, а с момента настройки и навсегда.

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