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

Весной этого года наша команда получила заказ на нагрузочное тестирование и оптимизацию нескольких версий CMS 1C-Битрикс. Прекрасная задача, но как ее делать? В этой статье мы поговорим о том, как правильно тестировать и что вообще означает “нагрузочное тестирование”? А в следующих — как мы тестировали Битрикс и что у нас получилось.

Цели

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



Лирическое отступление. Несколько лет назад, проект “Рамблер-Фото”, проводится нагрузочное тестирование. Системные администраторы внимательно изучают поведение системы. Результат странный – большую часть времени система проводит в System Mode (это можно увидеть простой утилитой top). Это означает, что вместо выполнения кода проекта работает операционная система, тратя время на переключения контекста и выполнения системных вызовов.

По результатам анализа (совместного с программистами) оказалось, что HTML::Mason (шаблонизатор, используемый в проекте Рамблер-Фото) при каждом запросе осуществляет нескольких десятков проверок наличия различных файлов “по умолчанию”. Одна директива в настройках HTML::Mason’а решила проблему.

Как проводить?

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

Нагрузка дается на систему в совокупности!

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

Нагрузка дается в течение длительного времени

Как должен выглядеть поток пользователей? Ответ простой – максимально приближенный к реальным условиям. Самый лучший вариант — взять реальный сайт на 1С-Битрикс и реальные лог-файлы и, проанализировав их, составить:

Профиль нагрузки

Пользователи не только ходят по разным страницам, но и ходят по-разному. Беда любого крупного проекта — пользователи на модемах ;) Представьте себе — такой медленный вальяжный пользователь запрашивает страничку, подключается к тяжелому mod_php-серверу, сервер быстро-быстро ее обрабатывает и уже готов вернуть пользователю. И пользователь медленно-медленно начинает эту страничку забирать, например, со скоростью 1 килобайт в секунду. Таким образом при размере странички в 100 килобайт наш php-сервер будет занят 100 секунд, почти две минуты.

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



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

Соответственно, тестировать мы должны с учетом того, что часть пользователей у нас будет медленно забирать результат быстрой работы сервера:

Нагрузочная система должна имитировать медленных пользователей

Ну и последнее правило на сегодня — вспомните пример, который мы привели в начале этой статьи:

За нагружаемой системой наблюдают все: тестировщики, администраторы и разработчики!

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