Home

Оригинал статьи: http://techbeacon.com/how-create-highly-effective-performance-tests

Автор: Эмбер Рейс (Amber Race)

Перевод: Ольга Алифанова

Такие термины, как тестирование производительности, нагрузочное и стресс-тестирование часто используются как синонимы. Однако замер скорости работы сервиса и измерение возможной нагрузки на него – это не одно и то же, а подтверждение способности сервиса справиться с нормальным уровнем нагрузки не означает, что он так же среагирует на очень высокую. Как же создавать высокоэффективные тесты производительности, не налепив распространенных ошибок?

Вначале определитесь, чего вы ожидаете от сервиса, и что именно вы хотите проверить. Ваше приложение – "заяц", обязанный максимально быстро отвечать на вопросы? А может, это "черепаха", которая выигрывает гонку благодаря постоянно поддерживаемой скорости?

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

Вот с чего нужно начинать.

Понимание службы

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

• Ваш сервис – часть микросервисной архитектуры, с большим количеством зависимостей от других служб?
• Зависят ли другие службы от вашей?
• Нужно ли вашему приложению управляться с крупными файлами (изображения, звук)?
• Где находится ваш сервис физически по отношению к базе данных или клиентской базе?
• Чем отличается тестовое окружение от реального? Примите во внимание количество серверов, память, сеть, и другие параметры.

Знание входов и выходов вашей службы поможет вам выявить слабые места и преобразовать низкоуровневые результаты в возможную производительность в релизе.

Понимание приложения

Когда ваша служба вышла в релиз, нагрузку на нее будет генерировать не тест-скрипт, а клиентское приложение посредством реальных пользователей. Понимание, как именно приложение использует службу – это ключ к созданию релевантного теста производительности. Поэтому до того, как запустить JMeter, запустите ваше приложение через прокси и проанализируйте запросы. Вот на что нужно обратить внимание:

• Последовательность запросов при запуске, отличается ли она для новых и вернувшихся пользователей?
• Последовательность запросов для основного сценария использования. Такой сценарий один, или их несколько?
• Как различается профиль запросов для анонимных и авторизованных пользователей?
• Есть ли точки, на которых приложение заметно подтормаживает, ожидая ответа сервера?
• Не создает ли приложение ненужную нагрузку, дублируя запросы или слишком часто отправляя их?

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

Понимание пользователей

Чтобы определить линию отсчета для вашего сервиса, нужно знать количество пользователей и их ожидаемые шаблоны поведения. Ожидания от сервиса, предназначенного для обработки покупки товаров со всего мира в Черный Понедельник, отличаются от ожиданий от сервиса, поддерживающего пару сотен бета-тестировщиков. Вот о чем еще стоит подумать:

• Будут ли пиковые моменты, когда использование приложения многократно возрастет? Если да, насколько велик этот пик?
• Какова средняя продолжительность сессии в приложении?
• Сколько раз в день средний пользователь будет использовать приложение?
• Какой процент базы пользователей авторизован, какой – нет?
• Чего ожидают ваши пользователи от времени отклика приложения?

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

Понимание целей тестирования

Просто получить задачу "тестирования производительности" недостаточно. Спросите себя и команду, какую наиболее важную информацию должно предоставить такое тестирование?

• Способен ли сервис выдержать ожидаемую нагрузку?
• Максимальная пропускная способность, поддерживаемая сервисом при приемлемом уровне ошибок?
• Как добавление новой фичи повлияет на общую серверную производительность?
• Как быстро сервис отвечает на ключевые запросы?
• Как быстро сервис отвечает на запросы под ожидаемой нагрузкой?

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

Советы для тестирования производительности

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

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

Советы для нагрузочного тестирования

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

Вот пример вычисления нагрузки: представьте себе приложение, в котором ожидается 100000 активных ежедневно пользователей, с пиковой нагрузкой 30000 в час. Если каждая сессия продолжается пять минут – это дает нам 2500 пользователей одновременно в любой момент времени.

Советы для стресс-тестирования

Тестируя на стресс, возьмите свой скрипт и выкрутите его на максимум. Посмотрите, насколько далеко вы можете зайти, прежде чем система рухнет. Наиболее очевидный способ это сделать – это прогонять тест, наращивая количество цепочек, пока система не перестанет отвечать. Другой подход – оставить скрипт на ночь или на выходные и посмотреть, что будет. Это особенно хорошо срабатывает со скриптами, связанными с большим количеством сохранения и чтения данных.

Вперед, к победе в гонке производительности!

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

Обсудить в форуме