Ответ 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.