Пример отчета услуги Нагрузочное тестирование

Пример отчета по услуги Нагрузочное тестирование.

Нагрузочное тестирование серверов **** от 13 августа

Описание результатов тестирования

Тестирование проводилось на всех фронтендах напрямую. Запросы раскидывались из теста по round-robin в обход проксирующего nginx и какой-либо балансировки, чтобы избежать появления сторонних артефактов. Полученные тесты сравниваются с результатами теста с теми же настройками tsung от 20 июня. По сравнению с предыдущим тестом значительно увеличилось время коннекта, поскольку тестирование 13 августа и 20 июня производилось с разных географически удаленных внешних по отношению к тестируемому сайту серверов.

По сравнению с 20 июня стало возможным обслуживать до 3500 одновременных пользователей в пике, причем при нагрузке не превышающей 1000 одновременных пользователей (первая фаза теста) отказов в обслуживании почти не возникало, а при резком повышении нагрузки их число стало возрастать лавинообразно. Сначала возросло число ошибок 502, что говорит о забивании очереди бэкенда (апача), а потом вследствие увеличения среднего времени выполнения php-кода увеличилось число ошибок 504 (которые отдавались когда nginx не получал в течение установленного таймаута ответа от апача).

По сравнению с 20 июня мы можем удерживать разумное для одного сервера количество одновременных пользователей и при этом только после 1000 одновременных пользователей появляется существенное число ошибок 502 и 504, а не практически с начала теста, и их число растет только с ростом нагрузки, что говорит об увеличении пропускной способности сайта до минимально необходимой для запуска. Вместе с тем сайт в текущей конфигурации не потянет серьезную нагрузку в пике.

При этом в пике фронтенды загружаются по процессору практически полностью, по памяти при этом запас остается и процессорное время, как и раньше, уходит на задания по крону и обработку результатов большого числа запросов к базе. Сервер базы данных при этом загружается примерно на 50% и в силу большого числа запросов максимально возможного в текущей конфигурации виртуального сервера одновременного числа подключений к базе данных недостаточно для обслуживания потоков запроса в пике одновременно, они встают в очередь, что и увеличивает время генерации страницы и приводит к ошибкам 504.

В новом тестировании возросло максимальное время соединений и максимальная длительность сессии почти в два раза по сравнению с предыдущим тестом, но и пиковая нагрузка, принимаемая на себя сервером возросла с 2500 до 4000 одновременных пользователей.

В текущей конфигурации 4000 одновременных пользователей на сервер скорее всего верхняя планка по нагрузке, поскольку дальнее увеличение нагрузки либо перегрузит фронтенды по процессору либо нагрузит базу данных выше имеющихся ограничений по ресурсам.

Варианты оптимизации:

1 Увеличить мощность текущего сервера базы данных (прежде всего объем оперативной памяти) и добавить еще 1-2 слейва

2 Принять меры к возможному уменьшению числа одновременных запросов на страницу.

3 Провести профилирование медленных запросов на предмет их оптимизации

Кроме того, стоит отметить, что на данный момент из кэша запросов базы данных отдается только 22% от всех выборок, то есть при текущем состоянии и размере выборок query cache не эффективен и возможно разумно его отключить. Число джойн-запросов без индексов судя по всему несколько уменьшилось и по сравнению с числом чтений мало.