Как увеличить очередь сообщений для PHP7-FPM

80 порт это http, php-fpm это fastcgi - разные сервисы. Не знаю как можно было их перепутать, у тебя ж в конфиге php-fpm рядм с баклогом указан его порт.

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

php-fpm на 9000 порту висит обычно

Так-то он обычно файловый сокет слушает.

А и кстати, длина очереди и количество одновременных клиентов это совсем разные штуки. Про второе ни в sysctl ни в netstat ничего не пишется т.к. ядро его не ограничивает. С помощью какого опыта ты определил что максимальное число клиентов 511?

Оказывается «Apache2, php7.4 и fpm» - это 3 разных человека :)

которая случается веб-сервером на 80-м порту

Случается там бывает очередь.

Но эта очередь рассасывается сразу после установления соединения, а не после обработки запроса.

Сначала соединение обрабатывает web-сервер, потом устанавливает соединение с php-fpm и тот обрабатывает запрос.

• ss -lnt упорно для 80-го порта показывает максимальное значение в 511.

• 511 - это хардкод в FPM или можно как-то изменить?

порт 80 никак не связан с настройкой php-fpm. у web-сервера своя настройка backlog.

backlog в процессах не может быть выше чем установлен в sysctl.

максимальное количество одновременно обрабатываемых клиентов сервером равно 511

Оно ограничивается совсем другими настройками. В web и php-fpm они у каждого свои.

511 одновременных воркеров ты скорее всего не хочешь. Если воркер ведёт какие-то вычисления, то тебе понадобится суммарно 512 процессорных потоков или 256 ядер при включенном ht/smt. 511 воркеров это может потребовать довольно много оперативки. Если воркер не ведёт активных вычислений, то он ждёт ответ от чего-то. Чаще всего от базы данных. Твоя база данных сдюжит 512 параллельных запросов?

80 порт это http, php-fpm это fastcgi - разные сервисы. Не знаю как можно было их перепутать

Понял. Теперь не буду перепутывать.

у тебя ж в конфиге php-fpm рядм с баклогом указан его порт

Указан, только порт задавался к IP-адресу, а я php7-fpm и httpd2 настроил на использование файлового сокета.

php-fpm на 9000 порту висит обычно

На файловом сокете, поэтому наверное listen.backlog в выводе ss -lnt не отображался.

А и кстати, длина очереди и количество одновременных клиентов это совсем разные штуки.

Разные, но очень сильно зависимые. При подаче нагрузки на сервер клиентами очередь начинает заполняться.

С помощью какого опыта ты определил что максимальное число клиентов 511?

1. На Веб-сервере написал bash-скрипт в котором выводились результаты работы команд каждую секунду: #netstat -an | grep SYN_RECV | wc -l #nstat -az | grep -i listen #ss -lnt | grep «0:80» | wc -l #ss -lnt | grep «0:80» #ss -nt | grep «0:80» | wc -l #ss -nt | grep «0:80» | tail -1
2. со другой машины генерировал веб-клиентов командой: #ab2 -n 10000 -c 1000 http://IP-WEB-SERVER/

В итоге в зависимости от изменения числа в параметре -c я видел сколько у меня клиентов появляется на сервере, как растут очереди и как растут дропы и переполнения. Если были дропы и переполнения, то тест ab2 через определённое время завершался ошибкой apr_socket_recv: Connection reset by peer (104)

Оказывается «Apache2, php7.4 и fpm» - это 3 разных человека :)

Да, теперь и я об это в курсе.

Оно ограничивается совсем другими настройками. В web и php-fpm они у каждого свои.

Дело было в настройках Apache2. В итоге в конфиге Apache2 я создал параметр ListenBackLog в значение 1234, перезапустил Apache2 и вывод команды #ss -lnt для 80-го порта мне показал в поле Send-Q значение 1234.

Подача нагрузки в 1234 клиентов с помощью ab2 была полностью переработана Web-сервером.

Таким образом планка в 511 была преодолена. Причина проблемы была в том, что когда я смотрел конфиг Apache2 и не найдя параметра ListenBackLog почему-то не попытался его создать и задать ему значение.

И что там именно росло, где 511 было что ты решил что это количество подключённых клиентов? Правильный способ - взять количество ESTABLISHED в выводе netstat -an и вычесть из него длину очереди (Recv-Q) в netstat -nlt. ESTABLISHED это и подключённые клиенты и ожидающие в очереди.

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

511 - это число стояло в Send-Q при выводе команды #ss -lnt и оно не изменялось никогда: была или не была нагрузка.

При подаче нагрузки росли параметры Recv-Q в выводах команд #ss -lnt | grep «:80» и #ss -nt | grep «:80» -lnt - это количество подключений в очереди listen -nt - в очереди established Также я подсчитывал количество строк в выводе #ss -nt | grep «:80» | wc -l и выводил на экран.

И как только я подавал нагрузку на Веб-сервер, то я видел, изменение всех параметров. Однако когда подавал большую нагрузку, например от 700 одновременных соединений, то видел, что в параметре по подсчёту количества строк у меня доходил до 660 и больше не рос и при этом увеличивались значения параметров TcpExtListenOverflows и TcpExtListenDrops. Вот если значения этих параметров начинали расти, значит это был верный признак того, что тест ab2 через какое-то время срубится. И он срубался на ошибке 104.

Хотя, конечно, бывают случаи когда действительно нужна очередь больше 500, но не всегда.

А как тогда создают высоконагруженные сайты? Неужели этот параметр оставляют по-умолчанию? Это же получается, что если клиентский запрос тяжеловесный и не может быть моментально обработан Веб-сервером, то пропускная способность сервера будет 511 +- соединений. Это как-то слишком маловато для одного сервера, разве нет?

Правильный способ - взять количество ESTABLISHED в выводе netstat -an и вычесть из него длину очереди (Recv-Q) в netstat -nlt. ESTABLISHED это и подключённые клиенты и ожидающие в очереди.

Это наверное так и есть. Сейчас я убедился в том, что после изменения параметра ListenBackLog в конфиге апача - я смог нормальным образом подать нагрузку на Веб-сервер в виде 1234 одновременных клиентов. А раньше мог только 511. Есть прогресс.

Забыл сказать, что тест ab2 генерирует циклическую постоянную нагрузку от одновременных клиентов в течении некоторого времени минуты, 2х, 3х, ну сколько задать в параметре -n, соответственно при выводе параметров очередей на Веб-сервере я вижу постоянно загруженные очереди в течении этого времени, потому что когда один клиент получил ответ от веб-сервера, он не прекращает своё существование, а продолжает долбить Веб-сервер сколько может. Может быть поэтому у вас сложились сомнения относительно моего неправильного понимания очередей?

511 - это число стояло в Send-Q при выводе команды #ss -lnt и оно не изменялось никогда: была или не была нагрузка.

Кажется это просто максимальная длина очереди из конфига. То есть это не длина очереди которая есть сейчас (она в Recv-Q) и тем более не количество уже подключённых клиентов.

Также я подсчитывал количество строк в выводе #ss -nt | grep «:80» | wc -l и выводил на экран

Это очередь+коннекты, в твоём случае это видимо в основном очередь была, но поскольку ты не пишешь точно что именно делал и видел то сложно сказать.

Однако когда подавал большую нагрузку, например от 700 одновременных соединений

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

А как тогда создают высоконагруженные сайты? Неужели этот параметр оставляют по-умолчанию? Это же получается, что если клиентский запрос тяжеловесный и

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

не может быть моментально обработан Веб-сервером, то пропускная способность сервера будет 511 +- соединений. Это как-то слишком маловато для одного сервера, разве нет?

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

нагрузку на Веб-сервер в виде 1234 одновременных клиентов. А раньше мог только 511. Есть прогресс.

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

нафига этот комбайн городить если есть более производительный nginx UNIT?

511 - это число стояло в Send-Q при выводе команды #ss -lnt и оно не изменялось никогда: была или не была нагрузка.

Кажется это просто максимальная длина очереди из конфига. То есть это не длина очереди которая есть сейчас (она в Recv-Q) и тем более не количество уже подключённых клиентов.

Да, так и есть похоже что.

Это очередь+коннекты, в твоём случае это видимо в основном очередь была, но поскольку ты не пишешь точно что именно делал и видел то сложно сказать.

Я говорил, что я написал скрипт и какие команды в него вставил. Мне проще показать на скрине или в видео, что я делаю, но не знаю можно ли в сообщениях давать ссылки на видео и как вставлять картинки.

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

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

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

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

Хммм, получается, что … по данной логике мой Веб-сервер должен моментально уметь разбираться со всеми клиентами? Но я же во что-то в конечном итоге должен упираться? Почему TCP-очереди не могут быть узким бутылочным горлышком? Если не они, то что? Процессор, память? Я ведь должен знать какое количество клиентов способен мой сервер обрабатывать.

если есть более производительный nginx UNIT?

Потому что в конечном итоге даже при более производительном ПО при повышении нагрузки я должен поймать то, во что я упираюсь в системе. В случае Apache2+PHP+PHP-FPM я упёрся в очередь.

А в nginx во что упрусь?

У нормально работающего она должна быть около нуля - сервер вовремя забирает соединения из очереди.

А почему у меня на моём сервере очередь загружена? Что с сервером не так? Почему он вовремя не забирает соединения из очереди? Как понять?

У меня при подаче даже 500 одновременных клиентов на Веб-сервер происходить загрузка процессора на 100%. Может быть в этом причина, что очередь у меня полная запросов на соединения? Клиентский запрос состоит из вызова phpinfo(). В чем может быть тогда причина медленного выполнения запросов? FPM+Apache2 может быть?

Хммм, получается, что … по данной логике мой Веб-сервер должен моментально уметь разбираться со всеми клиентами? Но я же во что-то в конечном итоге должен упираться? Почему TCP-очереди не могут быть узким бутылочным горлышком? Если не они, то что? Процессор, память? Я ведь должен знать какое количество клиентов способен мой сервер обрабатывать.

В очередь упираться невозможно. Ну сколько повторять? Если очередь начала расти значит сервер уже во что-то упёрся и у него уже всё плохо. Очередь не создаёт никакой вычислительной нагрузки сама по себе, это просто индикатор (следствие, не причина) того что сервер не успевает. Если ты уберёшь с неё ограничение то она будет копиться 500, 1000, 100000 соединений и все будут ждать пока сервер наконец их обработает. Никакой технической проблемы сделать очередь сколь угодно длинной нет, но это совсем не то что обычно нужно для сайта.

Не «моментально разбираться», а достаточно оперативно подтвердить ядру что он принял соединение. Сколько у тебя запросов в секунду приходит?

И нет такого понятия «количество клиентов», есть количество запросов в секунду или иногда в минуту считают.

Судя по тому что 100% загрузка проца - упираешся ты в него. Причины могут быть в основном две: 1) пхп, 2) шифрование (если используешь https). Насчёт первого пункта - настрой логи php-fpm чтоб он писал сколько времени он потратил на обработку каждого запроса и какой % проца в среднем использовал.

А, ну и в top посмотри какие процессы проц тратят больше.

Причины могут быть в основном две: 1) пхп, 2) шифрование (если используешь https).

Нет, шифрования пока что не касался. Надо с простыми вещами разобраться сначала.

настрой логи php-fpm чтоб он писал сколько времени он потратил на обработку каждого запроса и какой % проца в среднем использовал. Сколько у тебя запросов в секунду приходит?

Настроил. Собрал логи. Вот результаты:

1. запросов в секунду: 930
2. время на обработку каждого запроса: есть разные значения от 1 до 15 мс примерно.
3. % проца на обработку запроса: основная масса запросов 0.0%, но есть такие, что 300%, 700% и прочий бред.
4. процессы в top: php7-fpm pool www

И нет такого понятия «количество клиентов», есть количество запросов в секунду или иногда в минуту считают.

Да как же нет? Как мне тогда собрать систему, которая сможет обслуживать до XYZ клиентов, а если надо обслуживать более, чем XYZ то я говорю, что нужно вот такое вот вертикальное масштабирование и/или горизонтальное. Разве не так делается?

Что кому от количества запросов? Система может обработать до 100500 запросов в секунду и что? Это как? Много мало? Запросы же бывают разные. Количество запросов это разве абсолютный показатель?

А вот если система может обработать до 100500 клиентов в секунду это уже как-то можно прикинуть, что приличное количество.

300% это какая-то ерунда и правда, может неправильно смотришь?

access.format = "ms=%{mili}d kb=%{kilo}M cpu=%C%% \"%{REQUEST_URI}e\""

строка в php-fpm.conf похоже выглядит? Больще 100% там неоткуда взяться по идее, да и 0% тоже неоткуда.

Вообще, если предположить что там везде 100% на самом деле, то 1000 запросов в сек по 10мс загрузят на максимум 10 ядер проца, и это норм.

Хотя может апач что-то портит неправильным приёмом по сети. Проверь ещё в php.ini output_buffering - дефолтно там 4096, изменится ли что-то если 1000000 поставить?

А, ну и про запросы в секунду я спрашивал больше про реальную систему а не про тестовый флуд запросами.

Да как же нет? Как мне тогда собрать систему, которая сможет обслуживать до XYZ клиентов, а если надо обслуживать более, чем XYZ то я говорю, что нужно вот такое вот вертикальное масштабирование и/или горизонтальное. Разве не так делается?

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

Запросы же бывают разные. Количество запросов это разве абсолютный показатель?

Конечно разные, чтоб быть ещё точнее надо учитывать ещё и тяжесть каждого запроса, но это уже слишком сложно для быстрой оценки ситуации. Но вот ты заметил что запросы разные, а то что клиенты ещё намного более разные - почему-то не замечаешь.

А вот если система может обработать до 100500 клиентов в секунду

Нет никаких клиентов в секунду.

строка в php-fpm.conf похоже выглядит?

access.format = «%R - %u %t "%m %r%Q%q" %s %f %{mili}d %{kilo}M %C%%»

Проверь ещё в php.ini output_buffering - дефолтно там 4096

; output_buffering ; Default Value: Off ; Development Value: 4096 ; Production Value: 4096

Изменил. Ничего не изменилось. Такие же 300, 200, 1000%.

Upd. Изменил формат журанала, поставил access.format = «%R - %u %t "%m %r%Q%q" %s %f %{mili}d %{kilo}M %C%%» - бредовые % остались.

Изменил формат журанала

Вроде старая и новая строка одинаково выглядят.

Ну, видимо это ошибки округления из-за того что ему очень не хватает времени. Сколько ядер проц/процы?

Поставь скорость запросов поменьше, может числа придут в норму. Начни вообще с того что в браузере эту страницу пооткрывай и посмотри что в пхп логе остаётся в плане миллисекунд и %cpu.

Вообще, если предположить что там везде 100% на самом деле, то 1000 запросов в сек по 10мс загрузят на максимум 10 ядер проца, и это норм.

Это эмпирические данные? Исходя из них я могу рассчитать сколько мне нужно ядер для Веб-сервера?

Сколько ядер проц/процы?

2 ядра Intel Core i7-6700K 4 GHz

Начни вообще с того что в браузере эту страницу пооткрывай и посмотри что в пхп логе остаётся в плане миллисекунд и %cpu.

Милисеки в норме. На двадцать ручных запросов из браузера - в логах 2 записи по 972% подряд.

Поставь скорость запросов поменьше

Не могу. ab2 вроде не даёт возможность изменять скорость запросов.

Может 97.2 а не 972? И ты милисекунды не написал какие получились.

Сколько процессов php-fpm создано? Поставь static 10 штук и проверь с ними.

Запросы, выполняющие только phpinfo, очевидно, тратят проца меньше чем реальный сайт, так что нет. Смотреть надо на реальном сайте, именно на том который ты хочешь хостить. И вообще, мог бы его просто запустить и дальше смотреть есть ли проблемы.

Сколько процессов php-fpm создано? Поставь static 10 штук и проверь с ними.

Поставил max_children в 10. Проверил на ab2. Время обработки колеблется от 1 мс до 15 мс. У некоторых запросов есть и по 59 мс.

Может 97.2 а не 972?

Нет. Я могу отличить . после трёх цифр, там именно сотни процентов в логах указаны. (Скрин могу здесь вставить?).

И ты милисекунды не написал какие получились.

При ручном запросе от 1 мс до 5 мс, при автоматизированном ab2 от 1 мс до 15 мс с пиками до 59 мс.

Смотреть надо на реальном сайте, именно на том который ты хочешь хостить. И вообще, мог бы его просто запустить и дальше смотреть есть ли проблемы.

Так нет реального сайта. Чтобы его запустить надо оборудование купить. А чтобы его купить, надо сначала понять сколько и чего покупать. А чтобы понять сколько и чего покупать, надо понять, какое количество запросов может обработать один сервер. Как-то так.

В таком случае то, чем ты занимаешься - бесполезная трата времени. Тесты запуска phpinfo() вот вообще ничего не скажут о способности сервера хостить некий неизвестный сайт. Захости его на этом компе для начала а там смотри чего будет хватать или нет. Если это не какое-то коммерческое мероприятие с агрессивной раскруткой то большой посещаемости у тебя скорее всего не будет и будет что-то меньше 1 запроса в секунду.

Захости его на этом компе для начала а там смотри чего будет хватать или нет.

Так ведь уже. Два виртуальных ядра загружены под 100% запросами phpinfo().

Нужна какая-то методика определения технических характеристик сервера под задачи, чтобы сначала спроектировать, а потом создать.

Метод: сначала создать, потом подать нагрузку, смотреть что не хватает, а потом докупать - мне не подходит.

Спасибо за активное участие и помощь в траблшутинге. Было очень полезно!

Так ведь уже. Два виртуальных ядра загружены под 100% запросами phpinfo().

Твой сайт - это страница с phpinfo? Зачем его хостить?

Нужна какая-то методика определения технических характеристик сервера под задачи, чтобы сначала спроектировать, а потом создать.

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

Метод: сначала создать, потом подать нагрузку, смотреть что не хватает, а потом докупать - мне не подходит.

И тем не менее он по факту единственный, так как у тебя, как я понял, нет не только самого сайта, но и хотя бы приблизительного представления о том, насколько он будет посещаемым.

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

а зачем вам увеличивать? если все работает то мучится не надо.

а зачем вам увеличивать? если все работает то мучится не надо.

Загрузка процессоров на 100% и очередь входящих TCP-соединений наполняется и держится вплоть до прекращения нагрузки.

Твой сайт - это страница с phpinfo? Зачем его хостить?

Да, это самый простой сайт, который я смог придумал. Мне не надо его хостить. Это ведь вы предлагаете такой вариант: захостить и посмотреть, что будет с нагрузкой, может быть и ничего не надо будет делать.

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

Совершенно согласен. Я как раз об общих приципах и подходах к проектированию систем по данной задаче и хочу узнать. Для этого я запустил локально у себя две виртуальные машины. Одна - создаёт нагрузку, другая - её обрабатывает и уже на первом этапе столкнулся с тем, что процессоры загружены на 100%, очередь TCP - полна. С вашей помощью было выяснено, что это не нормальное состояние очереди, проблема в загруженном процессоре и что он не успевает очередь разгребать. Вопрос: и что дальше делать? Где здесь я могу применить общие принципы и в чём они?

И тем не менее он по факту единственный

Нет, метод не единственный. Есть второй, кардинально отличающийся по-сути от первого: спроектировать по общим принципам и потом запустить в работу без необходимости кардинальных изменений в топологии инфраструктуры.

так как у тебя, как я понял, нет не только самого сайта, но и хотя бы приблизительного представления о том, насколько он будет посещаемым.

У меня есть представление, что будет на сайте, из чего он должен состоять функционально, но не количественно. Разумеется я предполагаю, сколько примерно клиентов должно быть, но сколько их в реальности действительно будет, я не знаю и полагаю, что это нормально.

Есть такое понятие времён СССР как инженерия. Это когда проектирование системы не слишком сильно отличается от того, для чего оно предназначено. Вот хотелось бы так же, а не так: возьми запусти и посмотри, что будет - если будет что-то не так, то докупи ещё чего-то. Это ведь не профессионально.

если загрузка процессора то надо смотреть каким приложением грузит и его оптимизировать и если это vds то добавить количество ядер.

если грузится апаче то надо блокировать ДДОС и увеличивать ядра.

Пытался отвечать по абзацам, но получается слишком длинно, поэтому просто приведу ряд существенных фактов.

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

2) Связать интересующее тебя «количество пользователей» и объективное «количество запросов в секунду» без детального анализа устройства и способа использования конкретного сайта невозможно, поэтому про «количество пользователей» пока что придётся забыть; аналогия из реального мира: допустим, тебе поставили задачу спроектировать, какого размера (в сантиметрах) и сколько электричества в сутки должен потреблять технический прибор на 5 человек, но не уточнили: это холодильник, телевизор, стиральная машина или микроавтобус. Очевидно, в таких условиях ты ничего сказать не сможешь.

3) Если тестируешь выдерживание нагрузки на сайт, то главным итогом работы будет количество обработанных запросов в секунду. ab его выдаёт в своём отчёте. Соответственно, он сравнивается с тем, что ты хочешь (меньше или больше) и узнаёшь, хватает этого железа или нет.

4) Надо учитывать, что нагрузка, которую создаёт ab, это совсем не то же самое что нагрузка, создаваемая реальными пользователями, и чем сложнее устроен сайт, тем больше между ними расхождение. Для сложных сайтов флуд запросами на один и тот же адрес малопоказателен. Да, теоретически можно просчитать заранее профиль запросов к сайту и всё спроектировать, но на практике это нецелесообразно - затраты на эту возню будут больше чем просто купить железо с большим запасом, не устраивая точных подгонок. Кроме того, этот запас будет в любом случае полезен на случай неожиданных ситуаций.

5) В твоём запуске ab было настроено -c 1000 - это 1000 параллельных запросов. При этом процессорных потоков у тебя явно меньше, реально работать будет не больше чем количество потоков, остальные будут ждать - либо в очереди процессов на процовое время, либо в очереди tcp-соединений, либо ещё где-то. Где именно будут ждать - зависит от настроек веб-сервера, пхп и скриптов сайта. «Ждать в очереди на проц» - самый плохой вариант, и чтобы его не случалось, у пхп есть настройка pm.max_children, куда надо прописать адекватное ограничение (для простых скриптов типа phpinfo это меньше чем количество процовых ядер, умноженных на 1.5 если есть гипертрединг, а для сложных сайтов отдельная история т.к. там скрипт не всегда занимает проц). Ставить -c заметно больше чем max_children смысла нет, это будет только искажать результаты.

если загрузка процессора то надо смотреть каким приложением грузит

php-fpm

и его оптимизировать

Сегодня это php-fpm, завтра apache, последзавтра nginx, через неделю СУБД - где поймать тот момент, когда надо либо оптимизировать бинарники (!?!) либо признать, что система не справляется с нагрузкой?

надо блокировать ДДОС

До ДДОС пока ещё не дошли

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

2. Связать интересующее тебя «количество пользователей» и объективное «количество запросов в секунду» без детального анализа устройства и способа использования конкретного сайта невозможно, поэтому про «количество пользователей» пока что придётся забыть; аналогия из реального мира: допустим, тебе поставили задачу спроектировать, какого размера (в сантиметрах) и сколько электричества в сутки должен потреблять технический прибор на 5 человек, но не уточнили: это холодильник, телевизор, стиральная машина или микроавтобус. Очевидно, в таких условиях ты ничего сказать не сможешь.

Ну ок, хорошо.

3. Если тестируешь выдерживание нагрузки на сайт, то главным итогом работы будет количество обработанных запросов в секунду. ab его выдаёт в своём отчёте. Соответственно, он сравнивается с тем, что ты хочешь (меньше или больше) и узнаёшь, хватает этого железа или нет.

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

4. Надо учитывать, что нагрузка, которую создаёт ab, это совсем не то же самое что нагрузка, создаваемая реальными пользователями, и чем сложнее устроен сайт, тем больше между ними расхождение. Для сложных сайтов флуд запросами на один и тот же адрес малопоказателен. Да, теоретически можно просчитать заранее профиль запросов к сайту и всё спроектировать, но на практике это нецелесообразно - затраты на эту возню будут больше чем просто купить железо с большим запасом, не устраивая точных подгонок. Кроме того, этот запас будет в любом случае полезен на случай неожиданных ситуаций.

Совершенно с этим согласен, что сейчас при использовании утилиты ab2 профиль нагрузки создаваемый ею совсем не тот же самый, который будет у реальных пользователей. С запасом согласен, а что если сначала купить, потом убедиться в том, что железа не хватает, то потом докупить? Вот меня этот вариант не устраивает вообще и нисколько.

5. В твоём запуске ab было настроено -c 1000 - это 1000 параллельных запросов. При этом процессорных потоков у тебя явно меньше, реально работать будет не больше чем количество потоков, остальные будут ждать - либо в очереди процессов на процовое время, либо в очереди tcp-соединений, либо ещё где-то. Где именно будут ждать - зависит от настроек веб-сервера, пхп и скриптов сайта. «Ждать в очереди на проц» - самый плохой вариант, и чтобы его не случалось, у пхп есть настройка pm.max_children, куда надо прописать адекватное ограничение (для простых скриптов типа phpinfo это меньше чем количество процовых ядер, умноженных на 1.5 если есть гипертрединг, а для сложных сайтов отдельная история т.к. там скрипт не всегда занимает проц). Ставить -c заметно больше чем max_children смысла нет, это будет только искажать результаты.

Для своей ВМ с 4-мя гигами оперативки в max_children ставил значение 92 исходя из эмпирического значения потребления 30 МБ оперативки каждым запросом в php. В итоге память загружена на 50%, процессоры - на 100%. В итоге значение параметра -с в ab2 мне надо ставить не более 100?

Для своей ВМ с 4-мя гигами оперативки в max_children ставил значение 92 исходя из эмпирического значения потребления 30 МБ оперативки каждым запросом в php. В итоге память загружена на 50%, процессоры - на 100%. В итоге значение параметра -с в ab2 мне надо ставить не более 100?

Если говорить про связь -c и max_children то где-то так. Но тут дело ещё в другом. Ты пишешь у тебя 2 ядра проца (предположим что именно 2 ядра без гипертрединговых ещё двух). Это значит, что когда придут два запроса, они полностью оба этих ядра займут. Дальнейшее увеличение max_children будет увеличивать накладные расходы на распараллеливание одного ядра на несколько разных процессов. При этом ставить max_children=2, думаю, всё-таки не стоит (поскольку какие-то непроцовые расходы всегда есть, да и повышенное max_children даст некоторую дополнительную гибкость), но ставить его больше 10 в описанных условиях точно незачем. Даже при 10 одновременных запросах сервер уже будет работать в неоптимальном режиме. Соответственно, в -c тоже лучше поставить не сильно больше чем max_children. Всё вышесказанное - исключительно про ситуацию, когда скрипт выполняется целиком своими силами. Если у тебя появятся обращения к базе данных, или какие-нить внешние http-запросы к другим сайтам, или даже просто массивное чтение с диска, то многие из php-процессов будут в состоянии «ждём ответа от кого-то, проц не занимаем» и поэтому количество процессов php можно ставить в несколько раз больше чем количество ядер проца (конкретное число настраивается по ситуации).

Можешь даже провести опыт: ставить разные max_children и смотреть как это влияет на количество обработанных запросов в секунду. max_children=2 будет примерно в 2 раза быстрее чем max_children=1, 3 будет ещё быстрее чем 2 (не знаю на сколько), 4, может быть, тоже, дальше скорее всего прирост скорости закончится и начнётся плавное её снижение. Может быть я чего-то не учёл и снижение начнётся чуть позже.