Мне, как человеку по долгу службы связанному с разработкой новой системы, часто задают один и тот же вопрос: «Сколько пользователей система тянет?». Очень неудобный вопрос, не правда ли? Мне всегда сначала хочется поупражняется в остроумии, и включить модель поведения «вредного админа»: задать несколько встречных вопросов, которые избавят меня на время от необходимости думать на эту непростую, но интересную тему:
• На какой конфигурации железа?
• Сколько времени должно «тянуть»?
• На каком начальном объеме данных?
Ну и контрольный выстрел: а что значит «тянет»?
Но, хочешь не хочешь, а отвечать надо. Об одном нелёгком поиске ответа на этот вопрос мой нижеследующий пост.
Что тянем?
Наш подопытный — это система документооборота ЕВФРАТ Е1. Совершенно новая система, написанная практически с нуля в течение последних 2-3 лет в недрах ООО «Когнитивные технологии».
Система имеет трёхзвенную архитектуру: БД (MS SQL), сервер приложений на базе IIS плюс толстый и мобильный клиенты. Основная платформа для разработки — .NET 3.5, основной язык — C#. Как это часто бывает, в процессе выпуска релиза уделялось некоторое внимание нагрузочным тестам, но недостаточное, чтобы понимать возможности созданной архитектуры. И на момент, когда жизнь заставила отвечать на главный вопрос поста, некоторая инфраструктура для нагрузочных тестов всё-таки существовала. Она была создана на встроенном инструментарии MS Visual Studio.
Мы подготовили стенд, включающий в себя средней мощности сервер (виртуалка Windows Server 2008 R2, 6 CPUs, 10 ГБ ОЗУ), на котором была развернута БД, сервер приложений и компьютер с тестами, имитирующими работу клиентских приложений. Общий сценарий тестов моделирует рабочий день типичной крупной организации. Каждый тестовый сценарий выполнял конкретную роль пользователя в делопроизводстве: регистратор, контролёр по документу и маршруту, исполнитель поручения, согласования и пользователь, который просто читал почту и просматривал доступные документы.
Процентное соотношение ролей пользователей в общем сценарии представлено на рис.1. Такое распределение было принято после небольшого маркетингового исследования клиентов на предыдущей версии системы.
Рис.1.Распределение по сценариям.
После долгих дискуссий, мы определили для себя что же такое «тянет»? Это бесперебойная работа сервера по описанной выше модели сценариев, в течение 8 рабочих часов и без серверных ошибок. При этом, процент неудачно выполненных клиентских тестов не должен превышать 0,5% (возможны ошибки в бизнес-логике тестов, непредвиденные таймауты и т.д.). Измерению будет подлежать максимально возможное количество одновременно подключенных пользователей (тестов) при выполнении всех описанных выше условий.
Как тянем?
Следующая проблема, которую пришлось решать: как именно подобрать это самое оптимальное количество пользователей? Делать множество запусков по 8 часов занятие долгое и не благодарное. По этому, было предложено количество одновременных тестов изменять динамически, чтобы получить оптимальный показатель за один 8-ми часовой прогон. Но в зависимости от чего? Вариантов чем определять загруженность сервера много: очереди обработки запросов на сервере, скорость выполнения запросов на клиенте, количество ошибочных тестов и т.д…
Здесь стоит сделать небольшое отступление для лучшего понимания дальнейшего описания. Сервер приложений системы обрабатывает клиентские запросы следующим образом: все запросы поступают в одну очередь и ожидают своей обработки. Есть
настраиваемый пул рабочих потоков. В нашем случае, их было 12: по 2 на ядро
процессора. Последний запрос в очереди поступает на обработку первому
освободившемуся рабочему потоку.
В результате, после ряда экспериментов был сделан вывод, что оптимально
определить количество пользователей в нашем случае — это мерить загруженность
этих рабочих потоков. Вычислялась она, как отношение времени загруженности потоков к времени их простоя, выраженное в процентах. Таким образом, 50% означает, что рабочий поток половину времени простаивает, 90% — рабочий поток почти все время загружен. Функция управления достаточно проста: загруженность в пределах 70-90% считается нормальной. Если загруженность потоков меньше 70%, то добавлялся новый тест, а если же больше 90% — один из тестов больше не запускался.
Что же получили в результате? В идеале, мы хотели получить прямую линию, показывающую оптимальное количество пользователей в конце теста для данной конфигурации. К сожалению, оно так и не «устаканилось». (см. график на рис.2)
Рис.2. Результат автоматического определения оптимального количества пользователей.
В результате 8 часов работы теста:
• Размер БД – 9719,50 Мб;
• Документов в БД – 4885;
• Поручений в БД – 14478.
Хорошо видно, что отклонение от среднего значения, равное 270 пользователям, невелико. Понятно, что так определилось оптимальное количество пользователей в «интенсивном» режиме нагрузки на сервер для данной конфигурации железа. Естественно, что в реальной жизни пользователи так с системой не работают, т.е. показатели 1000 и более одновременных пользователей на более мощных конфигурациях вполне по зубам.
Хочется оговориться сразу, что процесс был достаточно длительный, т.к. по ходу тестирования долго подбирались параметры управления нагрузкой на сервер, исправлялись ошибки на сервере и клиенте и т.д.
Что вытянули?
Если вам нужно отвечать, сколько же система «тянет» или на подобный хитрый вопрос, то нужно придерживается нескольких простых правил:
1. Чётко поставить задачу — что мы хотим узнать о нашей архитектуре в определённом окружении?
2. Формально определить что именно мы хотим измерить, и какой величине этот показатель должен соответствовать?
3. Зафиксировать все остальные возможные параметры тестирования, которые мы можем зафиксировать: конфигурацию железа, сценарии тестов, их распределение и т.д.
4. В процессе приближения к ответу на поставленный вопрос, не отвлекаться на другие интересные и непрогнозируемые исследовательские задачи.
Можно этот ряд правил рассматривать как отправную точку для тех, кто планирует заняться задачами измерения и улучшения производительности, но с чего начинать не понятно.
И под завязку, маленький хит-парад других «неудобных» вопросов, связанных с нагрузочным тестированием:
1. «Какой сервер нужен для XXX пользователей?»
2. «Сколько объектов можно ввести в систему? Место не кончится?»
3. «Какая скорость в сети должна быть, чтобы всё работало быстро?»
4. И мой любимый: « Если купим мощный сервер, падать перестанет?»
Как видите, простор для будущей работы нам обеспечен. Надеюсь, что инструментария Visual Studio для этого вполне хватит…
Автор: cognitech
