Если вы все знаете о нагрузочном тестировании и как правильно к нему подготовиться, то вам статья будет не интересна. Статья рассчитана на тех, кто хочет понять как строить “правильные” профили для тестирования и на что необходимо обращать внимание при подготовке сценария. Речь будет идти о Web-системах с Web-интерфейсом.

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

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

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

Количество соединений и последовательность выполнения

Возьмем несколько наиболее популярных браузеров (Google Chrome, Mozilla FireFox, Internet Explorer) и попробуем открыть любой сайт. Как показала практика работы с браузерами у некоторых есть настройка какое количество соединений они могут открывать параллельно, некоторые сами регулируют данное количество. К тому же количество соединений может меняться в зависимости от используемого типа соединения.

Internet Explorer:



Google Chrome:



Например я видел как для одного и того же ресурса https создавалось разное количество параллельных соединений. Так Google Chrome создавал 6 соединений и все запросы обрабатывал в рамках этого количества, а вот Internet Explorer мог создавать до 20 — 30 параллельных соединений.

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

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

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

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

Сторонние ресурсы

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



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

Группировка

Необходимо группировать запросы по выполняемым действиям. Так можно создавать отдельные группы на открытие главной страницы, на вход в систему, на переход по ссылке и т. д. Это все нужно в основном только для того, что установить необходимые задержки между группами действий. Мы рассматриваем одного виртуального пользователя как пользователя, который реально работает с системой. Естественно при наличии 100, 200, 1000 и более реальных пользователей, каждый из них будет проводить на определенной странице разное количество времени. Следовательно трафик должен идти от виртуальных пользователей неравномерно. Поэтому между группами действий необходимы устанавливать задержки. И чем более реальными они будут, тем более реальные результаты тестирования вы будете получать.



Заключение

Мы можем проигнорировать количество параллельно выполняемых соединений, сторонние ресурсы, группировки и задержки. Но в результате мы можем получить результаты тестов где видно, что система работает с 200 виртуальными пользователями (потоками), а на практике получите только 10 реальных. Или получить прямо обратные результаты, когда по графикам мы видим только 200 пользователей могут работать с системой, но с учетом разного времени использования страниц, количество используемых соединений и исключения сторонних ресурсов, мы можем получить и 500 реально работающих.

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

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

https://habrahabr.ru/post/332862/