Нагрузочное тестирование или почему ваш сайт работает медленно

Нагрузочное тестирование или почему ваш сайт работает медленно

На какое максимальное количество посетителей рассчитан ваш сайт, чтобы он “не тормозил”? Этот вопрос важно задавать на этапе разработки, тогда вы сможете избежать проблем в процессе его работы.

Сайт жутко тормозит, сделайте что-нибудь!

Практически каждая веб-студия  сталкивается с задачами по оптимизации производительности сайта. Как правило, это происходит тогда, когда сам клиент обращается к разработчикам с запросом вроде: “Сайт жутко тормозит, сделайте что-нибудь!”.

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

Лучшее, что в этом случае можно сделать - остановить рекламу, но не всегда это возможно (когда, например, вы заранее проплатили всю сумму за размещение баннера на другом сайте, и снимать его уже никто не будет).

Поэтому, говоря о производительности сайта, уместно вспомнить поговорку: “Готовь сани летом, а телегу зимой”. Это значит, что нужно заранее получить представление о том, сколько же посетителей сайт может выдержать.

Почему сайт работает медленно?

В подавляющем большинстве случаев это означает как минимум одну из проблем:

• Неоптимизированный или плохо оптимизированный код;
• Ограничения хостинга (низкий тариф, слабое “железо”, сетевые задержки).

Даже если ваш сайт сегодня работает быстро, задайте себе следующие вопросы: 

1. Каково максимальное количество посетителей на сайте, при котором скорость генерации страниц является ещё комфортной для пользователей?
2. Каково максимальное количество посетителей на сайте, приводящее к его полной недееспособности (отказ от сервиса)?
3. За счёт чего сайт выйдет из строя при повышении нагрузки (в первую очередь): процессорного времени, исчерпания оперативной памяти, закупорки сетевого канала?

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

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

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

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

1. Что именно позволяет измерить сервис: только время генерации страниц или же полное время загрузки? В последнее входит и нагрузка на nginx, который обычно и ответствен за выдачу статического контента (javascript/css/картинки);
2. Вообще как много данных (таблиц, графиков) сервис предоставляет для анализа (чем больше данных и чем удобнее они представлены - тем лучше);
3. Сервис позволяет тестировать только определённую страницу или же поддерживает возможность создания достаточно сложных сценариев вроде оформления заказа?
4. Есть ли возможность проводить тесты по расписанию, откладывать выполнение на определённое время? Это особенно важно, если мы захотим протестировать ночью, ведь мало кто захочет специально для этого нарушать свой сон.
5. Каковы лимиты на одновременное количество соединений, хватит ли вам нагрузочной мощности?
6. Как долго идёт пинг от нагрузочного сервера до вашего (чем меньше, тем лучше).

На что обратить внимание при тестировании

1. Если вы хотите найти узкие места на сайте, то проводить тесты имеет смысл с выключенным кэшем (как самого Битрикса, так и низкоуровневого вроде кэша MySQL). Для его отключения нужно предусмотреть специальные скрипты, которые можно установить на cron.
2. Проводя тест сразу на максимальных настройках (количестве параллельных соединений), вы рискуете “уронить” сервер. Проводите последовательность тестов, постепенно увеличивая потоки.
3. Также обязательно отключайте контроль активности в Битрикс (или добавляйте исключения), иначе нагрузочные сервера быстро будут забанены, а оплаченный тест выполнится вхолостую.
4. Убедитесь в том, что максимальное количество соединений в MySQL выставлено в большее значение, чем прогнозируемое количество потоков тестирования (в противном случае вы получите ошибку базы данных “Too many connections”).

На какие цены ориентироваться? В первую очередь, нужно понять, что именно вы хотите проверить. Если вам достаточно узнать, сколько одновременных соединений выдержит сервер при запросе определённой страницы (например, главной, карточки или списка товаров), вероятно, вам подойдут бесплатные варианты. Например, loadme позволяет на протяжении 50 секунд создавать нагрузку до 200 потоков, это очень много!

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

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

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

Отдельно хочется подчеркнуть важность определения сценариев нагрузочного тестирования. Тут не всё так просто, и ключевая ошибка может закрасться с самого начала. Несмотря на то, что общая цель нагрузочного тестирования всегда так или иначе связана с желанием понять запас прочности сайта в плане его производительности, не всегда понятно, на что тратятся основные серверные ресурсы. Чтобы что-то тестировать, нужно иметь план тестирования: куда отправлять нагрузочных ботов. Иначе вы можете направить нагрузку на те части сайта, которые вообще не являются узким местом  – и получить очень хорошие результаты. А когда вместо ботов придут реальные пользователи – получите отказ от сервиса.

Это значит, что этапу запуска тестов всегда должен предшествовать этап моделирования действий пользователя. Открытие карточки товара или даже списка товаров вообще не эквивалентно оформлению заказа (в плане нагрузки). А оформление 16 заказов по 50 позиций и одного на 800 позиций  – это тоже совершенно разное.

Рекомендации из нашего опыта

Рекомендация №1. Перед тем, как составлять сценарии нагрузочных тестов, пристрастно изучите всю уже имеющуюся статистику. В идеале разместите на сайте как можно больше целей Яндекс.Метрики или Google.Analytics. Посмотрите картину по тем пользователям, что уже посещают ваш сайт: как они себя ведут, на какие страницы заходят, какие действия совершают и куда кликают.

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

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

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

Какие действия можно считать типичными для интернет-магазина? Перечислим основные:

1. Заход на главную страницу сайта;
2. Заход в список товаров;
3. Заход на последнюю страницу в списке товаров (постраничная навигация);
4. Заход в карточку товара;
5. Сортировка списка товаров;
6. Переключение количества товаров в списке (20/50/100 и т.д.);
7. Фильтрация товаров (компонент умного фильтра);
8. Поиск по сайту;
9. Добавление товара в корзину (из карточки/списка товаров);
10. Регистрация на сайте;
11. Авторизация на сайте;
12. Заход на страницу корзины с небольшим количеством товаров;
13. Заход на страницу корзины с большим количеством товаров;
14. Оформление небольшого заказа;
15. Оформление большого (оптового) заказа;
16. Оформление быстрого заказа (обычно через спец. форму).

Рекомендация №2. Воспользуйтесь профилировщиком Битрикс для сбора и анализа базовой статистики по затратам серверных ресурсов.

Несколько примеров

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

...то это почти наверняка значит, что сервер стал (быстро) выдавать ошибку, за счёт чего время реакции резко сократилось после скачка. В данном конкретном случае был достигнут лимит подключений к MySQL (Too many connections).

Далее приведём в пример некоторые случаи, с которыми мы сталкивались, и сделаем некоторые выводы. Вот график, предоставленный blazemeter’ом по нагрузке выбранной страницы тестируемого сайта:

На нём синяя линия - количество потоков, оранжевая - время ответа сервера (по сути, время генерации страницы). На протяжении первых минут кол-во потоков постепенно увеличивается до 50, а потом некоторое время держится на этом уровне до завершения теста.

А теперь запустим этот же тест на loadimpact.com (с теми же параметрами):

Здесь уже три линии: 1) Зелёная (верхняя) показывает количество потоков. Мы выставили те же настройки - постепенное увеличение до 50, что мы и видим; 2) Синяя линия означает время полной загрузки всех объектов на странице (html, css, js, картинки); 3) бордовая - время генерации html.

В данном случае мы видим полное подобие кривых общей загрузки и генерации html с примерной разницей в 1.5-2 секунды. Это достаточно хороший результат.

В целом же по данным графикам мы можем сказать, что сервер готов выдерживать нагрузку в 15-20 потоков без ощутимого падения производительности. При дальнейшем увеличении потоков будет пропорциональное замедление. В рамках теста на 50 потоках отказа сервера мы не получили, хоть он и выдавал страницу медленно (по 12-18 секунд).

А вот пример сайта, имеющего явные проблемы с производительностью:

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

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

Не откладывайте на потом

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

Однако задачи такого тестирования гораздо шире: это и поиск узких мест производительности на сайте, и определение “запаса прочности” сервера, и проверка балансировки нагрузки в веб-кластере, и подготовка нового сайта к публикации на продакшн.

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