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

4 Мар 2020   |   Сайты и интернет-магазины

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

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

Задача клиента

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


Что сделали мы

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

Перед проведением теста на сайте был выключен всякого рода кэш (самого Битрикса, базы данных MySQL). Результаты сведены в следующую таблицу*:

A

B

C

D

E

G

Описание страницы

Созданная нагрузка (потоков)

Сред. время генерации (с)

Среднее время загрузки (с)**

Макс. нагрузка сети (Мбит/сек)

Комфортность хита для пользователя (%)

Главная

100

0,535

2,26 / 2,8

650

36

Карточка товара

100

1,15

1,15 / 2,3

302

43

Список товаров

100

3,6

1,2 / 4,8

192

21

Поиск по цифровому артикулу

100

0,32

1,5 / 1,82

397

55

Поиск по буквенно-цифровому артикулу

100

2,7

1 / 3,7

204

27

Полнотекстовый поиск

50

10,8

0,8 / 11,6

26

9

* Здесь имеет смысл сказать, что для полноты картины нужно собирать данные и составлять несколько таких таблиц  – для разного количества потоков. То есть одни и те же страницы должны анализироваться, например, для 10 потоков, 20, 50, 100, 200 и т.д. Тогда будет видно то количество потоков, на котором начинаются проблемы с производительностью.

В нашем случае стояла конкретная задача посмотреть производительность сервера на 100 потоках, что и отражено в таблице (кроме последней строки, которую проверять на 100 потоках не имело смысла, так как уже на 50 были обнаружены серьёзные проблемы).

** В ячейках это колонки указаны парно: первое значение в паре являет временем с момента, когда страница отдана сервером, до момента, когда она полностью скачана клиентом; второе значение в паре  – время с момента отправки запроса и до моммента его полного скачивания. По сути, второе значение является суммой времени генерации страницы и собственно её скачивания.

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

  1. Анализ абсолютных значений по столбцам

Он позволяет выделить среди всего количества страниц потенциально проблемные. Это не значит, что именно они будут создавать основную нагрузку, потому что это напрямую связано с востребованностью этих страниц. А по этим данным нельзя сказать, как часто пользователи запрашивают ту или иную страницу (но это можно узнать по Яндекс.Метрике).

Время генерации (колонка “C”)

Мы видим, что список товаров и поиск по буквенно-цифровому артикулу работают достаточно медленно, а полнотекстовый поиск  – недопустимо медленно. При этом буквенно-цифровой поиск и список товаров – востребованные страницы. Это значит, что они вполне могут создавать основную нагрузку на процессор (из тех страниц, что попали в тестирование). Напротив, главная страница и поиск по цифровому артикулу генерируются сервером достаточно быстро. Карточка товаров  – на границе приемлемого значения.

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

Время загрузки (колонка “D”)

В этой колонке значения поделены на два: первое значение  – это непосредственное время скачивания данных, а второе –  время полной загрузки для клиента (генерация + скачивание). Для клиента наибольший интерес представляет время полной загрузки, потому что это, фактически, его время ожидания. И тут мы можем получить общую картину того, сколько придётся ждать клиентам сайта. Если мы видим значения более 1.5 секунд  – это повод подумать над тем, как улучшить ситуацию.

Нагрузка на сеть (колонка “E”)

Абсолютные значения в ячейках этой колонки показывают, какую ширину канала нам нужно выбрать, чтобы выдержать нагрузку. Но тут есть ряд оговорок. Тест проводится для случая новых пользователей. Фактически, это означает, что кэш их браузера пуст. Если в каждую единицу времени к нам будут приходить новые посетители  – то результат будет именно такой, как в таблице. Если же нам придёт 100 пользователей, которые начнут ходить по сайту, нагрузка на сеть будет существенно меньше (потому что общие для всего сайта статические ресурсы будут закэшированы).

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

Комфортность хита (колонка “F”)

В этой колонке за 100% принята скорость загрузки страницы за 1 сек. Значение в 50% будет значить, что страница открывается в 2 раза дольше по сравнению с эталоном. В идеале все значения должны быть от 100% и больше. В нашем же случае всё наоборот  – все значения существенно не дотягивают до этой границы.

Анализ колонки совпадает с анализом времени загрузки. Разница лишь в способе представления данных.

  1. Анализ абсолютных значений по строкам (между столбцами)

Например, следует обратить внимание на случаи, когда время генерации страницы мало, а время загрузки  – велико. В нашем случае это отчётливо заметно на данных по главной странице сайта (первая строка таблицы), которая отдаётся сервером за полсекунды, а загружается  клиенту – за три. Также мы видим, что именно эта страница создаёт максимальную нагрузку на сеть – при данных условиях это 650 Мбит/сек. Очевидно, что здесь что-то не так, и можно подозревать чрезмерно большое количество статики (изображений, стилей, шрифтов, javascript-кода) на странице. В нашем случае так и есть. Имеет смысл провести её оптимизацию: во-первых, убрать со страницы то, что можно убрать; во-вторых  – сжать то, что можно сжать (оптимизировать изображения по их размеру и качеству, объединить и сжать javascript и css).

Противоположную картину мы видим на странице полнотекстового поиска (последняя строка): она хоть и долго генерируется, но практически не нагружает сеть.

  1. Общий анализ столбцов между собой

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

В плане сети мы можем увидеть, например, что 100 Мбит-ного канала для такого сайта вообще недостаточно. Здесь определённо нужен как минимум 1 Гбит (а лучше два).

Также мы видим (колонка “D”), что время, уходящее на скачивание данных, достаточно велико. И в некоторых случаях оно пятикратно превышает время генерации (поиск по цифровому артикулу). Вообще говоря это повод не только оптимизировать всю статику на сайте, но и передать задачу по её доставке специализированным сервисам  – CDN. Это позволит разгрузить сеть, по которой явно наблюдается перегруз (колонка “E”).

Колонка “G” демонстрирует возможные показатели общей удовлетворённости работой сайта со стороны конечных клиентов (с точки зрения его производительности). И в нашем случае они оставляют желать лучшего.

Какие выводы мы можем сделать?

  1. Страницы списка товаров и поиска по буквенно-цифровому артикулу нуждаются в оптимизации производительности;

  2. Логика полнотекстового поиска нуждается в серьёзной оптимизации производительности и, вероятно, в полном пересмотре алгоритмов;

  3. На сайте требуется провести сжатие статики. Особо тщательно должна быть проанализирована в этом плане главная страница;

  4. Рекомендуется использовать CDN;

  5. Пропускную способность сетевого канала лучше повысить до 1 Гбит/сек на постоянной основе.

  6. На протестированном уровне нагрузки сервер, очевидно, начал тормозить на ряде страниц. Если сетевой канал будет 100 Мбит, то сервер с нагрузкой не справится. При 1 Гбит-ном канале хоть и наблюдаются задержки, но ошибок отказа от сервиса мы не получили, сервер продолжил работать.

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

Результаты

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



Вернуться к списку