Масштабирование Nginx и идентификация узких мест в кластере EC2

Question

Я разрабатываю большое приложение, и мне нужно загрузить его. Это кластер на основе EC2 с одним экземпляром HighCPU Ex.Large для приложения, которое работает с PHP / NGinx.

Это приложение отвечает за чтение данных с сервера redis, который содержит несколько значений ключа 5k - 10k, затем создает ответ, регистрирует данные на сервере mongoDB и отвечает клиенту.

Всякий раз, когда я отправляю запрос на сервер приложений, он выполняет все свои вычисления за 20 - 25 мс, что просто здорово.

Сейчас я пытаюсь выполнить нагрузочное тестирование и запускаю на своем ноутбуке приложение на основе php для отправки запросов на сервер. Многие тысячи из них быстро за 20 - 30 секунд. В течение этого периода загрузки всякий раз, когда я открываю URL-адрес приложения в браузере, он отвечает обратно со временем выполнения около 25–35 мс, что опять-таки здорово. Так что я уверен, что редис и монго не вызывают узких мест. Но для возврата ответа во время загрузки требуется около 25 секунд.

Высокая загрузка процессора, напр. Большой экземпляр имеет 8 ГБ оперативной памяти и 8 ядер.

Кроме того, во время нагрузочного теста команда top показывает около 4–6 процессов php_cgi, занимающих около 15–20% ЦП.

У меня 50 рабочих процессов в nginx и 1024 рабочих соединения.

Что может быть причиной узкого места?

Если это не сработает, я серьезно подумываю о переходе на целое Java-приложение со встроенным веб-сервером и встроенным кэшем.

ОБНОВЛЕНИЕ - увеличено значение PHP_FCGI_CHILDREN до 8, а время отклика уменьшилось вдвое

Answer 1

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

Что вы можете сделать сейчас: 1. Установите рабочий процесс на минимум (один рабочий на процессор, например, 4 рабочих процесса, если у вас есть 4 процессора), а рабочие подключения - на максимум (10240, например)

1. Настройте стек TCP через sysctl. Вы можете достичь предела стека, если у вас много соединений

2. Получение статистики из модуля nginx stub_status (вы можете использовать munin + nginx, он прост в настройке и предоставил вам достаточно информации о состоянии системы).

3. Проверьте nginx error.log и журнал системных сообщений на наличие ошибок.

4. Настройте nginx (уменьшите время соединения и максимальный размер запроса).

Надеюсь, это поможет вам.