Шевченко Я.Т.

Национальный технический университет Украины «Киевский политехнический институт»

Нагрузочное тестирование web-приложений

Вступление

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

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

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

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

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

Поставновка задачи

В качестве анализируемого web-приложения был выбран интернет-ресурс rozetka.ua – один из самых популярных в Украине интернет-магазин электроники, бытовой техники и других категорий товаров[2].

В качестве основных сценариев были выбраны:

· Загрузка домашней страницы

· Поиск товаров

· Добавление товара в корзину

Все сценарии проводились с выгрузкой всех встроенных ресурсов сайта (css, js, т.п.)

Для анализа системы были выбраны следующие показатели:

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

· количество ответов приложения в единицу времени (исключая сообщения об ошибке)

· время отклика приложения

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

251658240

Рис.1. Сценарий нагрузки системы

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

Результаты

Таблица 1. Сводные результаты

Действие	Количество запросов, м/с	Среднее время ответа, м/с	90% запросов выполняются быстрее, чем м/с	Минимальное время ответа, м/с	Максимальное время ответа, м/с	Количество полученных ошибок, %
Загрузка страницы поиска	37090	2072	9767	28	24120	2,67
Сервис поиска	35917	1257	2341	28	23183	1,67
Поиск в целом	36906	3329	12108	81	24120	4,31
Загрузка страницы продукта	37741	2009	9349	26	27672	2,55
Сервис добавления продукта в корзину	36550	1170	2002	25	23261	1,53
Сервис информации о доставке продукта	35871	1151	1524	23	23222	1,45
Сервис предложений похожих продуктов	35248	1313	3051	26	24846	1,49
Добавление в корзину в целом	37290	5643	15923	100	102280	6,88
Запрос домашней страницы	35566	1306	3814	10	21538	1,32
Сумма	363745	7808	24678	10	142280	2,54

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

251658240

Рис.2. Время отклика приложения

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

Для идеальной системы время отлика с ростом количества пользователей выглядело бы следующим образом[1]:

251658240

Рис.3. Время отклика идеальной системы с ростом количества пользователей

Рост времени отклика должна только в точке насыщения системы. Из чего можно сделать вывод о неверной конфигурации балансировщика на сервере.

251658240

Рис.3. Количество ответов в единицу времени

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

Выводы

Исходя из приведеного анализа графиков показателей эффективности можно сделать следующие выводы:

· среднее время загрузки страниц является приемлемым (порядка 3-5 секунд)

· время отклика системы растет линейно с увеличением количества виртуальных пользователей что свидетельствует о неверной конфигурации балансировщика

· количество ответов в единицу времени не зависит от количества виртуальных пользователей, что является хорошим результатом

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

Литература:

1. Автоматизация тестирования производительности: основные положения и области применения[Електронный ресурс]. – Режим доступа: http://svyatoslav.biz/technologies/performance_testing

2. Rozetka[Електронный ресурс]. – Режим доступа: http://uk.wikipedia.org/wiki/Rozetka

3. Memory Leaks, Load Balancing and Deployment Settings: Testing Lessons learned from the eCommerce industry[Електронный ресурс]. - Режим доступа: http://apmblog.dynatrace.com/2014/02/26/memory-leaks-load-balancing-and-deployment-settings-testing-lessons-learned-from-the-ecommerce-industry/