Как проводить профессиональное нагрузочное тестирование на примере решения для электронной коммерции AdvantShop

Мы продолжаем рассказывать о компаниях-разработчиках решений (ISV), использующих облачные технологии. В этом выпуске мы расскажем про применение облачных сервисов Visual Studio Team Services, Azure, Application Insights и других для профессионального нагрузочного тестирования коммерческих продуктов на примере AdvantShop – решения для электронной коммерции, разработанном на базе ASP.NET. Предыдущие статьи цикла вы всегда можете найти на Хабре по ссылке #isvcloudstory. — Владимир Юнев

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

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

Специалисты компании "Логрокон" производят тщательную подготовку к тестированию, которая включает:

1. Анализ требований и сбор информации о тестируемой системе
2. Определение целей нагрузочного тестирования
3. Конфигурация тестового стенда для нагрузочного тестирования
4. Разработка модели нагрузки (Профиль НТ)
5. Выбор инструмента для нагрузочного тестирования
6. Разработка методики нагрузочного тестирования.
7. Создание и отладка тестовых скриптов

Результаты тестирования оформляются в отчете, который содержит:

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

Перед нами была поставлена задача тестирования производительности интернет-магазина AdvantShop. На сегодняшний день рынок ИТ предоставляет большое разнообразие средств для проведения нагрузочного тестирования ПО. И первый вопрос, который необходимо было решить для себя – какому из инструментов проведения нагрузочного тестирования отдать предпочтение?

Вероятно, многие из вас слышали о таком средстве тестирования производительности как Load runner. Наличие большого числа Web-протоколов объясняется желанием разработчиков охватить большой спектр технологий и уровней «захвата» данных. Выбирая этот инструмент для проведения нагрузочного тестирования нужно определиться, что для нас важнее: нетребовательность к ресурсам или удобство создания, поддержки и использования скрипта. Оба критерия для нас важны при проведении нагрузочных испытаний, поэтому продолжим поиск подходящего для нас средства проведения тестирования производительности.

Помимо платных утилит для проведения тестирования производительности рынок предлагает и ряд бесплатных. Под обзор попал такой из бесплатных инструментариев как Apache JMeter. К сожалению, этот инструмент имеет достаточно много проблем и ограничений: он может не поддерживать необходимые протоколы; в нём отсутствуют удобные средства мониторинга; выдаваемые им результаты требуют дополнительной обработки. А поскольку специалисты «Логрокон» отвечают не только за качество услуг, но и за сроки их оказания - такому инструменту как Apache JMeter мы не отдали предпочтение для помощи в проведении работ по тестированию производительности интернет-магазина.

Какое бы из этих средств тестирования производительности мы ни выбрали, нам предстоит развертывание инфраструктуры нагрузочного тестирования и обеспечение самих же себя ресурсами для его проведения (сервера и другое оборудование).

Тестирование «у себя» вызывает определенные трудности:

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

Однако с этими проблемами помогает справиться облачная служба Microsoft Azure, при использовании которой можно выделить очевидные преимущества перед тестированием «у себя» и использованием других доступных средств:

• Быстрый выход качественного продукта на рынок
• Цена. Отсутствие и устранение капитальных расходов при доступе к тестовому окружению в облаке, которое масштабируется лучше, чем собственное.
• Использование знакомых инструментов
• Лучшее тестирование с “бесконечным” облаком
• Изолирование продакшн-серверов. Предотвращение влияния процесса разработки и тестирования и тестовых приложений на серверы работающие в коммерческой эксплуатации в компании
• Доступ из облака к существующим мощностям в компании
• Размещение в любом месте без лок-ина

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

Теперь немного подробнее об основных этапах проведения тестирования производительности в облаке Azure и о фишках, с которыми мы столкнулись при нагрузочных испытаниях.

Безусловным преимуществом для выбора Microsoft Azure при тестировании производительности интернет-магазина AdvantShop является тот факт, что сервер приложений и сервер БД развернуты в Azure - это существенно упрощает развертывание инфраструктуры нагрузочного тестирования.

Средства Microsoft Azure позволяют выполнять нагрузочное тестирование с помощью Visual Studio Team Services (ранее сервис назывался Visual Studio Online), либо с помощью Virtual Machine.

Нагрузочное тестирование с помощью Visual Studio Team Services (VSTS) позволяет автоматически создавать и конфигурировать всю необходимую инфраструктуру в облаке, разворачивая контроллер и необходимое количество агентов с определенными настройками. Результаты прогона того или иного теста всегда остаются в облачной базе VSTS, и к ним в любой момент можно получить доступ. Помимо доступного развертывания инфраструктуры нагрузочного тестирования стоит обратить внимание на мониторинг приложений, поскольку при проведении нагрузочных испытаний тестировщик обращается к нему снова и снова. VSTS позволяет прямо в процессе нагрузочного тестирования динамически подгружать необходимые счетчики производительности из телеметрии Application Insights. Возможности Application Insights выходят далеко за рамки снятия метрик, настроенных в Performance Monitor непосредственно на серверах приложения. Имея доступ непосредственно к коду приложения, можно передавать в Application Insights данные об отслеживании событий, метрик, трассировки, зависимостей и тому подобное. Посредством такого подхода можно вычислить, к примеру, как часто пользователи выбирают определенный компонент, как часто они достигают определенной цели или как часто возникают те или иные ошибки.

И все-таки при выборе между VSTS и развертыванием Virtual Machine мы отдали предпочтение более знакомой нам классической инфраструктуре с агентами и контроллером, хотя средства VSTS ничем не уступают. При этом подходе помимо имеющихся серверов IIS и DB необходимо создать виртуальные машины для контроллера и агентов тестирования. На отдельную виртуальную машину имеет смысл вынести Visual Studio, поскольку при использовании VS локально можем столкнуться с проблемой нехватки ресурсов для обеспечения необходимой нагрузки на приложение.

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

При развертывании VM для контроллера в настройках открываем следующие порты:

• TCP порт 445 для удаленного сборка счетчиков производительности
• UDP порт 1434 для SQL Browser и TCP 1433 для подключения к SQL серверу
• TCP порт для подключения к Test Controller`y 6901
• Remote Destop.

После настройки VM подключаемся к ней через RDP и устанавливаем TestController. Затем запускаем Test Controller Configuration Tools и указываем аккаунт, с которым подключались к виртуальной машине, отмечаем галочку Configure test controller for load testing. В строке SQL Server instance указываем полное DNS-имя VM (не localhost, а, к примеру, adv5controller.cloudapp.net\SQLExpress чтобы была возможность сохранять результаты теста при запуске VS с другой VM).

Загружаем и устанавливаем дистрибутив SQL Server Express по ссылке на UI.

Запускаем SQL Server Configuration Manager и включаем Pipe и TCP/IP протоколы. В настройках TCP/IP включаем все доступные IP адреса Enabled и для IPAll устанавливаем статический порт 1433.

В настройках Firewall`a разрешаем подключения на следующие порты:

• исходящие подключения на агент (порт 6910)
• входящие подключения к службе контроллера 6901
• входящие подключения к службе RPC для сбора счетчиков производительности – порт 445
• подключения к студии (фреймворку LoadTest), исходящий порт 6915
• входящие подключения на TCP порт 1433 и UDP 1434

Возвращаемся в Test Controller Configuration Tools и нажмаем Apply settings. Начнется процесс конфигурирования контроллера тестирования. В последнем сообщении будет warning, на который не стоит обращать внимания.

При развертывании VM для агента в настройках открываем следующие порты:

• TCP порт 445 для удаленного сбора счетчиков производительности
• TCP порт для подключения к Test Agent`y 6910
• Remote Desktop

После настройки VM подключаемся к ней через RDP и устанавливаем TestAgent.

В настройках Firewall`a следует разрешить подключения на следующие порты:

• Входящие подключения к службе контроллера 6910
• Исходящие подключения к контроллеру тестирования 6901
• Входящие подключения к службе RPC для сбора счетчиков производительности – порт 445

Запускаем Test Agent Configuration Tools, в настройках указываем свой аккаунт и прописываем строку подключения к контроллеру. После нажатия Apply Settings запустится процесс конфигурирования агента тестирования.

После успешного его завершения отобразится окно статуса подключения агента

Перейдем к настройке виртуальной машины с Visual Studio.

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

После настройки VM подключаемся к ней по RDP и в настройках Firewall’a прописываем следующие подключения:

• Открываем порт 6915 для входящих соединений
• Открываем порт 6901 для исходящих на контроллер
• Исходящие порты UDP 1434 и TCP 1433 для подключения к базе SQL
• Исходящий 445 для подключения к RPC

Создаем новое решение Web performance And Load Test Project. Добавляем в него UnitTestProject1. В SolutionItems добавляем новый файл типа TestSettings и открываем его. На вкладке Roles устанавливаем RemoteExecution и прописываем вручную DNS имя виртуальной машины контроллера.

В меню Load Test выбераем вкладку Manage Test Controller и проверяем, что студия может подключиться к контроллеру:

Затем создаем новый Load Test, на вкладке Counter Sets добавляем для снятия метрик машину, на которой установлено тестируемое приложение и выбираем хотя бы один из доступных по умолчанию наборов счетчиков.

Внутри созданного нагрузочного теста добавим необходимые счетчики производительности для сервера приложения. Для этого два раза нажимаем на созданный нагрузочный тест, правой кнопкой мыши добавляем Add counters в созданном ранее Counter Set’e. Аналогичную процедуру проделаем с сервером БД.

После чего можно добавить созданный Counter Set в Counter Set Mapping, чтобы система собирала счетчики в процессе прохождения теста. Теперь тест можно запустить. Результаты тестирования каждого прогона теста будут сохраняться в автоматически созданную на контроллере базу LoadTest.

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

Цель первого прогона: определение максимального числа одновременно работающих пользователей при сохранении времен отклика в пределах значения х4 от единичного прогона (в данном случае 5 секунд)

Для определения максимального числа одновременно работающих пользователей были определены следующие параметры сценария нагрузки: нагрузка плавно подается на протяжении 10 часов для фиксированного числа пользователей, начиная со значения 500 пользователей и увеличивается каждые 30 минут на 500 пользователей до значения 10 000 одновременно работающих пользователей.

По итогам этого теста можно заключить, что по истечении 1 часа 30 минут приложение начинает деградировать. Сопоставив эти данные с графиком количества активных виртуальных пользователей, делаем вывод, что времена откликов начинают превышать значение 5 секунд при одновременной работе 1 500 пользователей. Однако на протяжении всего теста, продолжительностью 10 часов, не было зафиксировано таймаутов, что свидетельствует о возможности приложения выдерживать нагрузку до 10 000 одновременно работающих пользователей с увеличением времени отклика.

Проведя второй тест с условиями одновременной работы 1 500 пользователей (по итогам предыдущего теста) на протяжении 3 часов, мы получили следующий график времен отклика, который говорит о том, что приложение интернет-магазин AdvantShop выдерживает нагрузку в 1 500 виртуальных пользователей без деградации.

Мониторинг утилизации ресурсов позволяет сделать вывод, что имеет смысл пересмотреть конфигурацию сервера БД с целью снижения CPU, однако и текущая конфигурация обеспечивает одновременную бесперебойную работу 1 500 пользователей.

Средствами облачной службы Microsoft Azure было проведено нагрузочное тестирование интернет-магазина AdvantShop, так же развернутого в облаке. Приняв во внимание рекомендации по оптимизации работы приложения, коллеги из AdvantShop выпустят новую версию приложения. А благодаря тому, что инфраструктура нагрузочного тестирования была развернута в облаке, мы обеспечили себе возможность в любой момент повторить нагрузочные испытания с минимальным временем на подготовку и развертыванием стенда с новой конфигурацией – достаточно перенастроить и запустить VM облаке.