Назад |
Перейти на главную страницу
рельсы 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, вам необходимо рассмотреть проблему, называемую «скачок времени» на виртуальных машинах, которая влияет на данные о времени отклика. Системные часы виртуализированы внутри гостевой операционной системы. Он замедляется, когда система используется, и его необходимо периодически повторно синхронизировать с базовыми часами хоста гипервизора. Когда это происходит, вам неизвестно или вы контролируете это. Он проявляется в виде более длинных средних и максимальных записей времени при тестовом прогоне, потому что эта повторная синхронизация времени действительно происходит, когда записи времени открыты для событий. Вы можете проверить это, используя элемент управления в вашем тестовом проекте, который работает на физическом оборудовании, таком как генератор управляющей нагрузки. Результаты элемента управления должны помочь проиллюстрировать величину перекоса данных из неконтролируемого набора.
- Вы работаете на виртуальной машине, что затрудняет получение высокоточных данных о том, какой ресурс вы фактически используете, из-за того, как гипервизор сообщает гостевой операционной системе, что используется.
- Здесь может пригодиться профилировщик кода или инструмент глубокой диагностики. Вы хотите явно искать условия слишком раннего выделения ресурса, слишком часто при вызовах кода или слишком долго перед освобождением ресурса в вашем коде. Это слишком раннее, слишком часто, слишком длинное представление, когда инженеры по производительности ищут в коде оптимизацию данного бизнес-процесса, поскольку элементы, попадающие в эти корзины, подвержены как времени отклика, так и проблемам масштабируемости в производственной среде.