"Тяжелые" одновременные пользователи Nginx - Laravel - Google вычислить движок

Я запускаю сервер в nginx с Laravel (средний статический web), и я делаю например 500 постоянных загрузок одновременных пользователей во время 1 минута (не распределенные пользователи в течение этой минуты).

И получив эту ошибку:

unix:/var/run/php/php7.1-fpm.sock failed - ресурс временно недоступен

cginx.conf

worker_processes auto;

events {
    use epoll;
    worker_connections 1524; #in my case it should be 1024, but well..
    multi_accept on;
}
http {
    #with this I reduce disk usage a lot
    client_body_buffer_size 10K;
    client_header_buffer_size 1k;
    large_client_header_buffers 2 1k;
    reset_timedout_connection on;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

www.conf

pm.max_children = 500
pm.start_servers = 20
pm.min_spare_servers = 20
pm.max_spare_servers = 64

Результаты с вычислительным двигателем Google:

f1-micro (1 vCPU, 0,6 GB) - Is supporting 40 - 60 requests per second
g1-small (1 vCPU, 1,7 GB) - Is maintaining 80 request per second
n1-standard (1vCPU, 3,75 GB) - - Is maintaining 130 request per second
n1-standard-2 (2vCPU, 7,5 GB) - Is maintaining 250 request per second
.
.
n1-standard-16 (16 vCPU, 60 GB) - Is maintaining 840 request per second

Последний первый тест проходит, остальные - ошибки Bad Gateways от 200 пользователей до 400

Если я тестирую, например, не 2.000 пользователей, распределенных за 30 секунд с микро-экземпляром, тогда это нормально, но не одновременная отправка запросов.

Начиная с 2-х ядер, уровень ЦП отлично выглядит, как и операции с дисками и т.д.

Итак, после loooot тестов у меня есть несколько вопросов:

1) Это нормально? Не для меня, не является нормальным, чтобы понадобилось 16 ядер для запуска простой сети.. или стресс-тест слишком тяжелый и нормальный?

2) Тогда я что-то упустил? Является ли Google ограничивать запрос в секунду каким-то образом?

3) Какими будут обычные параметры для заданных конфигурационных файлов?

Любая другая помощь более чем приветствуется

Ответ 1

TBH, не совсем ясно, что вы пытаетесь достичь с помощью этого теста, особенно с приведением GCE в уравнение.

Если ваш сайт "средней статической сети" выполняет дюжину SQL-запросов для каждой страницы, возможно, с несколькими JOIN для каждого, а также для различных других ресурсоемких операций, то вряд ли вам станет сюрпризом, что вы очень вдали от достижения C10K.

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

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

Ваш бэкэнд способен обрабатывать определенное количество запросов за определенный промежуток времени, порядка нескольких десятков в секунду на самом дешевом плане.
Он настроен без четкой спецификации того, что должно произойти, когда ресурсы исчерпаны. С помощью имеющейся конфигурации вы можете загружать только 40 запросов в секунду на самый дешевый экземпляр, однако конфигурация настроена на одновременный запрос на обработку Laravel 500 на 1 vCPU с общей суммарной ОЗУ, при этом каждый запрос составляет около 1 МБ RAM, что является способом в нижней шкале для "среднего статического веб-сайта", питаемого от динамической структуры, что приводит к несоответствию импеданса.
Вряд ли неожиданно, что вы получаете ошибки, что явно связано с несоответствием импеданса, поскольку противодавление растет, а бэкенд, скорее всего, исчерпывает RAM, обрабатывать бесконечные запросы.

Итак, что такое решение?

Решение состоит в том, чтобы иметь четкое представление о том, сколько ресурсов требуется для создания каждой страницы на бэкэнд, а затем ограничить количество одновременных подключений к бэкэнду от обратного прокси, чтобы никогда не превышать такое определенное количество подключений, с http://nginx.org/r/limit_req и/или http://nginx.org/r/limit_conn, так как подходящее. Таким образом, вы можете поймать и контролировать условия перегрузки и предоставить пользователю соответствующее сообщение об ошибке и/или script автоматическое изменение размера вашей инфраструктуры.

В дополнение к вышесказанному, еще одна хорошая идея - кэшировать результаты вашего бэкэнд при условии, что это фактически "статический" контент, созданный без индивидуальной настройки пользователя, который затем позволяет вам учитывать реалистичную ситуацию, когда ссылка на ваш сайт размещена на Slashdot/Reddit/Twitter, вызывая огромный всплеск трафика на одну "статическую" страницу, которую затем можно кэшировать в течение всего события. Иначе, если контент на самом деле не является "статическим", то вам решать, какой способ пойти и какой компромисс принять - я бы предложил посмотреть, действительно ли на заказ требуется индивидуальная настройка, и может ли нестандартная версия быть подходящим, особенно для сценариев, подобных Slashdot.

Ответ 1

Ответ 2