Highload: проверка ERP на прочность. Как это было

    Приветствую, читатель!
    В этой статье я расскажу, как мы тестировали производительность нашей платформы.

    Тестирование производительности мы планировали провести с самого начала разработки новой версии системы, поскольку реализовали множество оптимизаций. Однако, откладывали ввиду большой занятости, пока в один прекрасный день мне не сообщили, что удалось договориться о тестировании на Oracle Exadata Database Machine X2-2.
    Вот такой сервер внушает.
    Машина настолько мощная, что для наших тестов не потребовалось использовать ее всю. Собственно, нас интересовал вопрос, стало ли приложение более производительным, чем предыдущая версия.
    Предыдущая версия работала и работает у одного из клиентов, его параметры (количество пользователей, товаров на складе, складов, офисов, касс и т.п.) мы и взяли за базовые. В тестируемой конфигурации процессы повторяли процессы у этого клиента практически полностью (за исключением некоторых специфических функций), так что мы сняли статистику, какие роли пользователей генерируют основную нагрузку.
    Под нагрузкой мы пониманием создание документов, записей в справочниках, поиск по справочникам и тому подобную активность. Список ролей не стал неожиданностью, но провести формальную процедуру проверки интуиции посчитали необходимым. Считали роли по истории изменений и с использованием FGA (очень удобный функционал, мы его использовали для разделения доступа в новой платформе) — опять же приятное дополнение к основному назначению функционала.
    Итак, вот эти роли:
    • Менеджер закупки
    • Кладовщик, приемщик на складе
    • Создание заявок на пополнение склада
    • Кладовщик, набор перемещений
    • Менеджер по продажам
    • Кассир
    • Кладовщик, набор заказа на складе
    • Кладовщик отправка и прием межскладских перевозок

    Есть, конечно, множество аналитиков и начальников отделов и департаментов, которые целыми днями считают всевозможные отчеты, но эти отчеты рассчитываются на StandBy сервере, и нагрузки на Primary не создают, поэтому такого рода нагрузку из сценария решили исключить.

    В реальной ситуации большая часть заказов создается через сайт, а не людьми, и при этом происходит чуть меньше операций. Решили, что нам важна оценка сверху, и не стали отдельно моделировать сценарий для сайта.
    Сгенерили соответствующее число складов, офисов, товаров, менеджеров, касс и прочих объектов, построили распределение продаж товаров (если считать в штуках, то распределение почти точно совпало с формулой 80/20 — 80% продаж делали 20% ассортимента).

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

    Работа ролей эмулировалась внутри серверов приложений, запуском одного потока на каждого виртуального пользователя.
    Для начала, надо было проверить работу 4000 пользователей — для сравнения с реальным профилем. Oracle Database сервер запускался в виртальном окружении на 4-х ядрах и 8мью гигабайтами памяти. Сервера приложений были запущены на этом же сервере как виртуальные машины — 2 штуки, каждая с 2-мя ядрами и 2мя гигабайтами памяти. К нашей радости, сервер легко выдерживал, время выполнения операций было в рамках одной секунды, загрузка CPU около 60-70% и 50% IO, т.е. блокировок практически небыло, а железо использовалось достаточно эффективно.
    Показанные результаты превышали профиль реального клиента по всем параметрам.
    Кроме того, в распоряжении была вся машина и мы решили продолжить, увеличивая нагрузку на 2000 пользователей за каждый прогон (один прогон занимал 2-3 часа, 2 прогона проработали всю ночь).
    Опытным путем установили, что один сервер приложений (2 ядра, 2 Гб памяти) может выдержать 3000 пользователей.

    В итоге, дошли до цифры в 18 000 пользователей. Предпринимали попытки запуска на 20 000 пользователей, однако, результаты были нестабильны. Нестабильность объясняется стохастическим сценарием, и, как следствие, возникновением точек нестабильности, при попадании в которые система сваливалась в блокирование, из которого уже не могла выйти. Надо заметить, что при увеличении числа пользователей мы сохраняли профиль пользователей и прочие частотные характеристики — кол-во офисов, товаров, складов, касс и так далее. Т.е. виртуальная компания торговала тем же товаром через те же самые офисы, не открывая новых! Повторюсь, нам была важна реальная оценка «сверху», поэтому не стали высасывать из пальца как надо увеличить частотные характеристики. Как только у нас появится клиент на 18 000 пользователей мы снимем его профиль и попробуем мультиплицировать пользователей.

    В заключение


    В этой статье данно несколько лирическое описание процесса тестирования, формальное и полное описание можно найти на нашем сайте. На днях появилась новая версия Oracle Exadata Database Machine X5-2, и мы собираемся протестировать ее. Для повышения производительности попробуем воспользоваться такими функциями как in-memory database, поколоночное хранение и некоторыми другими.
    О результатах расскажем в нашем блоге. Не переключайтесь.
    Ultima
    43,00
    Компания
    Поделиться публикацией

    Комментарии 0

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

    Самое читаемое