Назад | Перейти на главную страницу

рельсы puma nginx одновременный доступ - не удается найти узкое место

У меня есть простое приложение rails, работающее на puma, с прокси-сервером nginx перед ним, настроенным стандартным образом. Они работают на экземпляре aws t2.micro.

База данных mysql работает на другом экземпляре t2.micro.

Если я запускаю нагрузочный тест jmeter для простого варианта использования входа с 20 одновременными входами, я получаю следующий результат:

summary +      1 in 00:00:03 =    0.3/s Avg:  2542 Min:  2542 Max:  2542 Err:     0 (0.00%) Active: 20 Started: 20 Finished: 0
summary +     79 in 00:00:06 =   13.7/s Avg:  1734 Min:   385 Max:  3246 Err:     0 (0.00%) Active: 0 Started: 20 Finished: 20
summary =     80 in 00:00:09 =    9.2/s Avg:  1744 Min:   385 Max:  3246 Err:     0 (0.00%)

Когда я запускаю тот же тест с 100 одновременными входами, я получаю следующий результат:

summary +    362 in 00:00:14 =   25.0/s Avg:  2081 Min:   381 Max:  9730 Err:     0 (0.00%) Active: 21 Started: 100 Finished: 79
summary +     38 in 00:00:13 =    3.0/s Avg:  4887 Min:   625 Max: 17995 Err:     0 (0.00%) Active: 0 Started: 100 Finished: 100
summary =    400 in 00:00:27 =   14.8/s Avg:  2347 Min:   381 Max: 17995 Err:     0 (0.00%)

Среднее и максимальное время отклика увеличивается в 2-5 раз. Это не является большим сюрпризом, но я не могу найти узкое место, когда смотрю на ЦП сервера и загрузку памяти. Максимальное использование ЦП во время тестирования составляет 36%, а потребление памяти практически не меняется (до 5 МБ).

Мои вопросы: где на самом деле узкое место? Какая стратегия масштабирования? Посадить рабочих puma на отдельные экземпляры EC2?

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

Пища для размышлений здесь:

  • Вы исследуете только два элемента в модели конечных ресурсов: ЦП и память. Вы пропустили элементы, связанные с диском и сетью.
  • Если вы запускаете свой инстанс JMETER на виртуальной машине внутри AWS, чтобы избежать расходов, связанных с загрузкой за пределами Amazon, вам необходимо рассмотреть проблему, называемую «скачок времени» на виртуальных машинах, которая влияет на данные о времени отклика. Системные часы виртуализированы внутри гостевой операционной системы. Он замедляется, когда система используется, и его необходимо периодически повторно синхронизировать с базовыми часами хоста гипервизора. Когда это происходит, вам неизвестно или вы контролируете это. Он проявляется в виде более длинных средних и максимальных записей времени при тестовом прогоне, потому что эта повторная синхронизация времени действительно происходит, когда записи времени открыты для событий. Вы можете проверить это, используя элемент управления в вашем тестовом проекте, который работает на физическом оборудовании, таком как генератор управляющей нагрузки. Результаты элемента управления должны помочь проиллюстрировать величину перекоса данных из неконтролируемого набора.
  • Вы работаете на виртуальной машине, что затрудняет получение высокоточных данных о том, какой ресурс вы фактически используете, из-за того, как гипервизор сообщает гостевой операционной системе, что используется.
  • Здесь может пригодиться профилировщик кода или инструмент глубокой диагностики. Вы хотите явно искать условия слишком раннего выделения ресурса, слишком часто при вызовах кода или слишком долго перед освобождением ресурса в вашем коде. Это слишком раннее, слишком часто, слишком длинное представление, когда инженеры по производительности ищут в коде оптимизацию данного бизнес-процесса, поскольку элементы, попадающие в эти корзины, подвержены как времени отклика, так и проблемам масштабируемости в производственной среде.