с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.

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

Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).

На втором этапе проводится нагрузочный тест (Load Test) , с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).

Как правильно подавать нагрузку на систему?

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

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

Так, во время тестирования бразильского видеопортала среднее время отклика от сервера составило 20 секунд при запуске тестов с рабочей машины в европейском регионе. А при запуске с виртуальной машины, развернутой в одной локальной сети с тестируемой системой, - 2 секунды. Таким образом, обеспечение наивысшей скорости обмена данными между клиентом и сервером, позволило протестировать приложение в условиях, приближенных к идеальным.

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

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

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

Дополнительные виды тестов производительности

Задачей объемного теста (Volume Test) является оценка производительности системы при увеличении объемов данных, хранимых в базе данных приложения. Схема подачи нагрузки при данном виде теста такая же, как и при нагрузочном. Для проведения теста требуется база данных, заполненная необходимым объемом данных. Так, при тестировании биллинговой системы для оператора мобильной связи, объем данных был выбран исходя из ее прогнозируемого наполнения через два года после выхода обновленной версии системы в производство.

Тест на стабильность (Stability Test) позволяет оценить работоспособность системы при длительной ожидаемой нагрузке в режиме работы 24/7. К примеру, если веб-сайт посещают пользователи, находящиеся в разных часовых поясах, уровень нагрузки может сохраняться постоянным. Помимо возможных перезапусков серверов системы под продолжительной нагрузкой, при тесте на отказоустойчивость также изучается влияние редких событий на деградацию производительности системы, например, работа сборщиков мусора.

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

Тестирование клиентской части vs . тестирование производительности

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

Наилучшим решением проблем со стабильностью и сбоями в работе веб-серверов является обеспечение двухуровневой архитектуры приложения: клиентской, или Front - end , части и серверной, или Back - end , части.

Пользователь открывает браузер и отправляет запрос к странице сайта на Front - end сервер. Запрос принимается и запрашивается у исполнительной части веб-приложения – Back - end сервера, который хранит логику приложения, обеспечивает выполнение PHP-скриптов и генерирует HTML-страницы. Front-end принимает сформированную страницу от Back-end и в качестве ответа на запрос пользователя передает ее в браузер. Получив страницу, браузер пользователя начинает ее отображение, что сопровождается отправкой серии запросов на графический контент и CSS. Эти запросы принимает Front-end и обрабатывает без обращений к Back-end’у.

Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Front-end применяется тестирование клиентской части, или Client - Side Testing , а для Back-end – тестирование производительности серверной части .

Основная цель тестирования клиентской части состоит в измерении времени, необходимого браузеру, для загрузки HTML-страницы. Наиболее важными показателями здесь являются количество загружаемых данных, их объем, а также количество выполненных запросов.

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

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

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

Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.

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

Тестирование производительности серверной части направлено на анализ выполнения запросов и получения соответствующего запроса от Back-end.

Цели данного вида тестирования:

• Измерить время отклика самых важных бизнес-транзакций;
• Определить предельный уровень допустимой нагрузки;
• Выявить «узкие» места в производительности системы;
• Составить рекомендации по улучшению производительности;
• Найти возможные дефекты, проявляющиеся только при одновременной работе большого количества пользователей.

Далеко не каждый пользователь современной компьютерной системы в повседневной работе сталкивается с понятием «нагрузочное тестирование». В основном оно знакомо веб-разработчикам и всем тем, кто использует ресурсоемкие программы. Тем не менее иногда знания в этом вопросе могут пригодиться и рядовым юзерам. Попробуем разобраться, зачем все это нужно.

Нагрузочное и цели

Прежде всего, стоит четко разграничить виды таких тестов. Условно их можно подразделить на два класса: проверка компьютерного «железа» при максимально возможной или чрезмерной нагрузке на каждый компонент и (веб-сайтов с элементами прогнозирования, отдельно взятых программ и т. д.).

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

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

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

Что же касается второго класса, тестирование сайта и сервера может выступать как некое универсальное средство прогнозирования их поведения в условиях реального функционирования. К примеру, это может быть эмуляция одновременного запроса доступа большого числа пользователей. Как известно, по такому принципу действуют DDoS-атаки, когда сервер или сайт не успевает обрабатывать слишком большое количество обращений. Нагрузочное тестирование сервера или сайта будет рассмотрено подробнее несколько позже. А пока займемся компьютерным «железом». Это касается не только домашних или рабочих терминалов, но и реальных физических серверных систем.

Тест процессора

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

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

При использовании утилиты для начала рекомендуется закрыть все активные приложения и отключить автоматический (сна), чтобы компьютер ненароком не отключился в процессе проверки. Теперь нужно смоделировать процессору самые жесткие условия (а программа может это сделать, как никакая другая, действительно ставя чипы в самые тяжелые условия). Сам тест активируется из меню опций, где выбирается раздел Torture Test. Там будут указаны виды проводимых операций. Наиболее интересными здесь представляются тесты Blend (одновременная нагрузка и на процессор, и на «оперативку»), а также Small FFT и Large FFT (увеличение нагрузки на процессор за счет выгрузки оперативной памяти).

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

Проверка работы оперативной памяти

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

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

Определение поведения графического адаптера

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

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

Кроме того, можно использовать и специальные утилиты, разработанные под конкретные игры. Например, очень хорошо подойдут тестовые приложения типа Alien vs Predator, S.T.A.L.K.E.R. или еще что-то в этом роде. Как правило, распространяются они совершенно бесплатно, а с их помощью можно точно установить, как будет вести себя система после установки оригинального игрового пакета.

Для чего нужно тестирование серверов и сайтов

Теперь несколько слов о том, что представляет собой тестирование сайта и веб-сервера. Об одном аспекте (DDoS-атаки) уже было сказано. Сейчас посмотрим на этот вопрос с другой стороны.

Сами тесты такого типа в некоторой степени можно отнести даже к маркетинговым инструментам по прогнозированию поведения пользователей. Так, например, можно смоделировать ситуацию поведения определенного количества (максимального/пикового) людей при входе на сайт, узнать, сколько страниц может просматриваться, будет ли задействована электронная почта, например, в процессе заказа товара, как информация может использоваться для идентификации посетителей, позволит ли предоставить одновременный доступ к сайту пользователям в определенный момент времени, будет ли востребовано подтверждение пользовательских полномочий третьим лицом (например, при вводе номера банковской карты), насколько эффективным окажется внедрение Java-апплетов или использование защищенного соединения https и т. д.

Вопросы теста веб-серверов (программного обеспечения) и создаваемых Интернет-ресурсов

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

В данном случае (и для сайта, и для веб-сервера) многие советуют использовать мощнейший пакет под названием OpenSTA (System Architecture Test), который позволяет не только провести проверку, но и разбить задачи на составляющие для каждого отдельно взятого элемента структуры с использованием инструмента создания и моделирования скриптов Script Modeler. Примечательно, что после создания такой модели можно проверить даже соединение по протоколу SSL (обязательно должен быть запущен так называемый сервер имен). Кроме того, результаты можно сохранять в разделе Repository Host, а тесты объединять в соответствующие группы.

Что в итоге?

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

Мы продолжаем рассказывать о компаниях-разработчиках решений (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 облаке.

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

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

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

Если посмотреть на , то видно что данный вид тестирования относится к клиенто-ориентированным тестам. Это означает, что обычно нагрузочные тесты проводятся на готовом продукте и в prod, либо prod-like окружении, не погружаясь в сам код. Чаще всего в моей практике, при помощи нагрузочных тестов мне нужно было определить насколько требователен написанный код к производительности сервера.

Jmeter

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

Поиск: jmeter, нагрузочное тестирование с jmeter

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

До сих пор мне не удалось полностью освоить все «фишки» Jmeter, поскольку он обладает Очень большим функционалом. Но основные задачи по созданию тестовых сценариев для нагрузки я освоил. Во время работы с jmeter, у людей, не знакомых с нагрузочным тестированием, появится достаточно много вопросов по новым терминам. Этому также способствует англоязычный интерфейс, записывайте непонятные названия и обязательно изучайте их по ходу. Например для меня это были thread и swap.

Поиск: thread, swap

Вариант интересной задачи для нагрузочного тестирования. Нужно проверить что web-приложение справится с 200 сотнями онлайн пользователей, которые будут заниматься перепиской во встроенном чате. Возможна масса вариантов таких заданий, которые можно решить написать самому. Поставьте себе задачу на каком-нибудь собственном проекте(чтобы не уронить чужой) и начинайте ее решать с помощью jmeter.

После изучения стандартных возможностей Jmeter я один раз сильно обжегся. Я совсем неправильно оценил собранные метрики и получил нагоняй от старшего коллеги. Из этого я сделал вывод — для тестирования нагрузки не достаточно знания только инструмента. Очень важно правильно оценивать собранные метрики после нагрузочных тестов и на их основании сделать правильный вывод.

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

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

Yandex Tank

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

Поиск: нагрузочные тесты yandex tank

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

Поиск: locust, нагрузочное тестирование locust

UPD. Есть несколько интересных онлайн сервисов для нагрузочного тестирования. Например loadimpact.com . Конечно масштабное нагрузочное тестирование там платное, но во всяком случае можно попробовать триальный режим.

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

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

Зачастую performance тесты проводят тогда, когда проблема производительности уже показала себя. Так было и в моем случае.

Часто повторяющиеся ситуации

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

Чтобы найти такие проблемы нужно иметь доступ к коду, базам данных, консоли сервера и отчетливо понимать что именно происходит. Здесь очень уместен и вообще умение работать с командной строкой.

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

Поиск: профайлеры кода

Еще здесь очень полезны системы мониторинга. К примеру Zabbix, Ansible и другие. С их помощью можно отслеживать потребляемые ресурсы тех или иных скриптов и строить долгосрочные отчеты. Эти системы используются в основном dev-ops командами, но также сильно помогут в тестировании.

На этом все. Надеюсь я показал в какую сторону копать и что практиковать. Буду рад вашим вопросам в комментариях.

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

Зачем производится нагрузочное тестирование:

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

Вообще, существует огромное количество инструментов для нагрузочного тестирования, как opensource, так и коммерческих. Остановимся на наиболее часто используемых и расскажем об их основных возможностях.

Apache HTTP server benchmarking tool

Бесплатный

Официальный сайт

Самый часто используемый, т.к входит в состав Apache.

Ab ://]hostname[:port]/path

где основные необходимые options:

C concurrency - количество одновременных запросов к серверу (по умолчанию 1);
-n requests - общее количество запросов (по умолчанию 1).

В результате команды получаем такой отчет:

Concurrency Level: 10 Time taken for tests: 0.984 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 3725507 bytes HTML transferred: 3664100 bytes Requests per second: 101.60 [#/sec] (mean) Time per request: 98.424 (mean) Time per request: 9.842 (mean, across all concurrent requests) Transfer rate: 3696.43 received Connection Times (ms) min mean[+/-sd] median max Connect: 1 2 3.6 1 23 Processing: 63 94 21.5 90 173 Waiting: 57 89 21.6 84 166 Total: 64 96 21.5 92 174

Плюсы :

• Есть везде, где есть Apache;
• Не требует никакой дополнительной настройки;
• Очень простой инструмент.

Минусы :

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

Joe Dog Siege

Бесплатный

Официальный сайт .

Немного сложнее ab и необходимые задачи выполняет гораздо лучше.

В файле-сценарии задаются URL-ы и запросы тестирования. Если сценарий большой по объему, то можно вынести все запросы в отдельный файл и в команде указать этот файл при тестировании:

# cat urls.txt # URLS file for siege # -- http://www.bitrix24.ru/ http://www.bitrix24.ru/support/forum/forum1/topic3469/?PAGEN_1=2 http://www.bitrix24.ru/register/reg.php POST domain=test&login=login http://www.bitrix24.ru/search/ POST

В команде указывается количество пользователей -с, количество повторений -r и задержку между хитами -d .

Результат можно выводить в log-файл или сразу в консоль в режиме реального времени:

HTTP/1.1 200 0.44 secs: 12090 bytes ==> GET / HTTP/1.1 200 0.85 secs: 29316 bytes ==> GET /support/forum/forum1/ HTTP/1.1 200 0.85 secs: 29635 bytes ==> GET /support/forum/forum1/ HTTP/1.1 200 0.34 secs: 12087 bytes ==> GET / [...] done. Transactions: 100 hits Availability: 100.00 % Elapsed time: 12.66 secs Data transferred: 1.99 MB Response time: 0.64 secs Transaction rate: 7.90 trans/sec Throughput: 0.16 MB/sec Concurrency: 5.02 Successful transactions: 100 Failed transactions: 0 Longest transaction: 1.06 Shortest transaction: 0.31

Также можно взять из access-log веб-сервера URL-ы, по которым ходили реальные пользователи и эмулировать нагрузку реальных пользователей.

Плюсы :

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

Минусы :

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

Apache JMeter

Бесплатный

Официальный сайт

Основные возможности:

• Написан на Java;
• HTTP, HTTPS, SOAP, Database via JDBC, LDAP, SMTP(S), POP3(S), IMAP(S);
• Консоль и GUI;
• Распределенное тестирование;
• План тестирования – XML-файл;
• Может обрабатывать лог веб-сервера как план тестирования;
• Визуализация результатов в GUI.

Результаты выводятся в графическом виде:

Плюсы :

• Кроссплатформенный, т.к написан на Java;
• Очень гибкий, используется много протоколов, не только веб-сервер, но и базы;
• Управляется через консоль и gui интерфейс;
• Использование напрямую логов веб-сервера Apache и Nginx в качестве сценария c возможностью варьирования нагрузки по этим профилям;
• Достаточно удобный и мощный инструмент.

Минусы :

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

Tsung

Бесплатный

Официальный сайт

Основные возможности:

• Написан на Erlang;
• HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP, Jabber/XMPP;
• Консоль (GUI через сторонний плагин);
• Распределенное тестирование (миллионы пользователей);
• Фазы тестирования;
• План тестирования – XML;
• Запись плана с помощью Tsung recorder’а;
• Мониторинг тестируемых серверов (Erlang, munin, SNMP);
• Инструменты для генерации статистики и графиков из логов работы.

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

Плюсы :

• Т.к на писан на Erlang, то хорошо масштабируется, зависит от выделяемых ресурсов;
• Может выполнять роль распределенной системы, на большом количестве машин;
• Большое количество тестируемых систем - не только веб-серверы и БД, но и, к примеру, XMPP-сервер: может отправлять сообщения, тесты с авторизацией;
• Управление через консоль, но, благодаря поддержке плагинов, можно управлять и с помощью стороннего плагина с gui-интерфейсом;
• Наличие в комплекте инструмента Tsung Recorder - своего рода, proxy-сервер, через который можно ходить по тестируемому сайту и записывать сразу как профиль нагрузки;
• Генерация различных графиков тестирования с помощью скриптов.

Минусы :

• Нет gui-интерфейса;
• Только *nix системы.

WAPT

Платный

Официальный сайт

Основные возможности:

• Windows
• Платный (есть триал на 30 дней / 20 виртуальных пользователей);
• Запись плана тестирования из десктопных и мобильных браузеров;
• Зависимости в планах тестирования (последующий URL в зависимости от ответа сервера);
• Имитации реальных пользователей (задержки между соединениями, ограничение скорости соединений).

Отчет можно вывести как таблицей, так и графиком.