rails puma nginx concurrent access - не могу найти узкое место
У меня есть простое приложение rails, работающее на puma, с прокси-сервером nginx перед ним, настроенным стандартным образом. Они работают на экземпляре aws t2.micro.
mysql db работает на другом экземпляре 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, то вам необходимо рассмотреть проблему, называемую "скачком часов" на виртуальных машинах, которая влияет на данные о времени отклика. Системные часы виртуализируются внутри гостевой операционной системы. Это замедляет работу системы и требует периодической повторной синхронизации с базовыми часами хоста гипервизора. Как раз в тот момент, когда это происходит, как неизвестно вам, так и управляется вами. Как это проявляется, это как более длинные средние и максимальные временные записи на вашем тестовом запуске, потому что эта ресинхронизация часов действительно происходит, когда временные записи открыты по событиям. Вы можете проверить это, используя элемент управления в вашем тестовом дизайне, который работает на физическом аппаратном обеспечении, например, генератор управляющей нагрузки. Результаты работы контрольного элемента должны помочь проиллюстрировать количество перекосов в данных из неконтрольного набора.
- Вы работаете на виртуальной машине, что очень затрудняет получение высокоточных чисел того, какой ресурс вы на самом деле используете, из-за того, как гипервизор сообщает гостевой операционной системе о том, что используется.
- Здесь может пригодиться профилировщик кода или глубокий диагностический инструмент. Вы хотите явно искать условия слишком раннего выделения ресурса, слишком часто в обращениях к коду или слишком долго перед выпуском ресурса в вашем коде. Это слишком рано, слишком часто, слишком долгое представление является то, где производительность инженеры смотрят в коде для оптимизации данного бизнес-процесса, как элементы, которые попадают в эти ведра склонны как время отклика и проблем с масштабируемостью в производстве.