Книга: Руководство по DevOps

Встраиваем тесты производительности в программу тестирования

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

Наша цель — написать и запустить автоматические тесты производительности, проверяющие производительность всего стека приложения (код, базы данных, хранилища, сети, виртуализация и так далее) в рамках конвейера развертывания, чтобы мы могли обнаруживать проблемы на раннем этапе, когда внесение исправлений делается быстро и обходится малой ценой.

Поняв, как наше приложение и среды ведут себя под нагрузкой, близкой к реальной, мы можем гораздо лучше планировать мощности нашей системы, а также выявлять нижеперечисленные ситуации и подобные им:

• время выполнения запроса к базе данных растет нелинейно (например, мы забыли включить индексирование базы данных, и время загрузки страницы увеличивается с тридцати секунд до ста минут);

• изменение кода вызывает десятикратное увеличение количества вызовов базы данных, нагрузки на системы хранения или сетевого трафика.

Если у нас проводятся приемочные испытания и они могут выполняться параллельно, то мы используем их как основу для наших тестов производительности. Например, предположим, что мы работаем с сайтом электронной торговли и определили, что операции «поиск» и «оформить заказ» важны и должны хорошо выполняться даже под нагрузкой. Для проверки этого мы можем запустить одновременно тысячи приемочных тестов поиска и тысячи приемочных тестов оформления заказа.

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

Чтобы в начале работы выявить проблемы с производительностью, мы должны регистрировать результаты тестов производительности и оценивать результаты каждого запуска по сравнению с предыдущими результатами. Например, мы можем посчитать, что тест не пройден, если производительность отличается более чем на 2 % от результатов предыдущего запуска.

Оглавление книги