|
 Автор: Демченко Дмитрий
Не смотря на возможно громкое название, речь в статье пойдет не о тестировании производительности ERP систем вообще, а о вполне определенной задаче, которую пришлось решать в рамках горизонтального и вертикального расширения системы ERP.
Под горизонтальным расширением я имею в виду – увеличение количества подключенных объектов к системе, таких как магазины, склады, супермаркеты.
Под вертикальным расширением, я понимаю добавление функциональных модулей в ERP систему.
Немного предыстории. В компании была внедрена ERP система Oracle JD Edwards. Был запущен финансовый модуль, транспортный, модуль, модуль складской логистики. С помощью ERP системы автоматизирована деятельность всех складов (семь по всей стране) и суперпермаркетов (около 30). Компания успешно работала и развивалась несколько лет.
Дальше встала задача, подключить к ERP системе все магазины, на тот момент примерно 400.
При этом надо было учесть дальнейший бурный рост. В компании существовали стратегические планы – в течении нескольких лет увеличить количество розничных магазинов с 400 до 1000.
Прежде чем запускать проект по подключению такого количества объектов к ERP системе, необходимо было тщательно все проверить и взвесить. Необходимо было ответить на следующие вопросы:
- Не ухудшится ли производительность работы ERP системы после подключения к ней всех текущих магазинов компании?
- Как сильно изменится производительность работы ERP системы после подключения еще 600 магазинов. Не станет ли производительность ERP помехой для реализации планов компании?
- Определить потребуется ли увеличение мощности оборудования серверов и систем хранения данных. И если потребуется, то необходимо оценить параметры оборудования.
- Определить архитектурные и функциональные доработки, которые необходимо будет сделать, для подключения магазинов к ERP системе.
Варианты решения
Существовало несколько путей получение ответов на заданные вопросы:
- Получить оценку на основании имеющейся статистики. Автоматизация хозяйственной деятельности в компании уже несколько лет была реализована в ERP. Другие словами за несколько лет работы накопилась определенная статистика о производительности работы системы, об изменении производительности после подключение одного объекта – в частности, склады подключались последовательно, один за другим. Поэтому, при желании можно было оценить, как менялась производительность после подключения очередного склада. Также имелась статистика о скорости прироста данных в базе данных и об изменении скорости прироста, после подключения очередного объекта. Кроме того, имелась статистика загрузки оборудования (CPU, памяти, дисковый ввод-вывод и пр.). В общем, можно было проанализировать цифры и получить некий прогноз с долей вероятности о точности данного прогноза.
- Воспроизвести подключение магазинов в тестовой среде, на имеющемся в компании тестовом оборудовании. Тестовое оборудование уступало продуктивному оборудованию по мощности в несколько раз. Поэтому воспроизвести работу всех магазинов было не возможно. Поэтому пришлось бы воспроизвести нагрузку только части магазинов. Полученные результаты после тестирования необходимо было бы пересчитать, учитывая разницу в мощности оборудования, разницу в количестве тестовых магазинов.
- Воспроизвести подключение магазинов к ERP системе в тестовой среде, но на оборудовании сопоставимом по параметрам с продуктивным оборудованием. В этом случае ответы на поставленные вопросы были получены практическим путем. Кроме того, желательно было бы иметь не просто тестовое оборудование точно такое же или близкое по параметрам с продуктивным, но имеющее возможность быстрого увеличения мощности. Такое увеличение потребовалось бы, если бы в процессе тестирования стало бы понятно, что текущей мощности оборудования не достаточно для подключения 400 магазинов к ERP.
Каждый из вариантов имел свои плюсы. В частности, плюсом первого варианта является его стоимость –дешевое решение. Собрать экспертную группу в составе функциональных и технических специалистов, системных администраторов приложения и базы данных. Сделать прогноз. Однако, минусом было бы то, что уровень точности оценки был бы не высок.
Плюсом второго варианта является более точная оценка по отношению к оценке первого варианта. Минусом, конечно же, являлось по-прежнему низкий уровень точности оценки, т.к. параметры тестовой среды очень сильно отличались от параметров продуктивной среды. Кроме того, этот вариант, был бы дороже, за счет того, что пришлось бы создавать модель нагрузки и сопутствующих ей роботов.
Третий вариант самый точный – но самый дорогой. Необходимо найти оборудование идентичное продуктивному оборудованию, там развернуть ERP систему (задача крайне не тривиальная), причем ERP система должна быть по параметрам (например, объем базы данных) аналогичная продуктивной ERP системе. Надо было бы создать генератор, который бы воспроизводил нагрузку на ERP систему, аналогичную той нагрузке, которую пользователи создают ежедневно, а это более 1000 пользователей работающих одновременно.
Результат был очень важен для компании. Цена ошибки была очень дорогой – от понесенных в пустую затрат на реализацию проекта, до потери времени, драгоценного в тех условиях. Кроме того, от результатов проекта зависел другой не менее важный для компании проект. В данном случае, время деньги.
Поэтому было принято решение идти по четвертому варианту, а именно сделать купаж из трех выше перечисленных пунктов. Таким образом, ответы на поставленные вопросы получались последовательно. Каждый раз оценка получалась все более точной.
Подготовка
Опущу описание получение прогноза на основании статистики и проведение частичного тестирования (варианты 1 и 2). Опишу третий вариант – т.е. проведение нагрузочного тестирования.
Тестовая площадка
1 Sun Microsystems Benchmark Center, г. Париж
Для проверки производительности работы ERP системы после подключения 400 и 1000 магазинов надо было найти оборудование (сервера, системы хранения данных). Продуктивная ERP система работала на оборудовании SUN Microsystems. На одной из вечеринок Sun Days In Novosibirsk представители компании Sun обмолвились о том, что у них имеются тестовые центры специально для целей тестирования. После нескольких обсуждений договорились с Sun о том, что нам предоставят требуемое оборудование в Benchmark Center в г. Париже, выделят сотрудников, которые помогут в проведении тестирования, и вообще всячески будут помогать в решении данной задачи. С Sun договорились о сроках проведения тестирования, о параметрах предоставляемого оборудования.
Генератор нагрузки
Договорившись о тестовой площадке, необходимо было создать генератор нагрузки. Это, пожалуй, самая сложная часть в подготовке к тестированию.
Первым шагом необходимо было провести тщательное, вдумчивое исследование. Задача усложнялась тем, что нагрузку на ERP систему необходимо было воспроизвести максимально близкой к нагрузке, которую наблюдают при ежедневной работе. Помимо этого, необходимо было иметь возможность регулировать параметры нагрузки. Сложность еще заключалась в том, что требовалось получить оценку изменения производительности ERP системы не просто неким обобщенным числом или высказыванием, например таким: «производительность ERP системы после подключения 400 магазинов снизилась на 40%», а получить изменение производительности системы по каждой ключевой операции: «Создания заказов закупки», «Приход на склад», «Создание инвойсов», «Создание ваучеров», «Заведение и редактирование номенклатурной позиции» и т.д. и т.п. Эти требования накладывали определенные ограничения на реализацию генератора нагрузки.
Для понимания модели нагрузки надо было:
- Составить список операций, которые ежедневно выполняются в системе.
- Определить объем данных, с которыми работает каждая операция. Например, в операции «Заказ поставщику» вводится от 5 до 999 позиций. И такую оценку необходимо получить по каждой операции.
- Определить, количество пользователей в системе, которые выполняют данную операцию. Например, операцию «Создание Заказов поставщику» выполняют 50 закупщиков
- Определить частоту выполнения каждой операции в системе, или объем порождаемых данной операцией документов. Например, в день создается 1000 заказов поставщику, т.е. каждый закупщик создает в среднем по 20 заказов. А вот операция «Сверка остатков» запускается в виде пакетного приложения один раз в день.
- Полученные операции необходимо сгруппировать. Операции, могут быть разные, но очень похожие. Соответственно, с целью уменьшение объема работ, имеет смысл создать одного робота. Например, операция «Приход товара» на московском складе, может немного отличаться от операции «Приход товара» на новосибирском складе. С точки зрения нагрузки, это различие в функциональности может не иметь принципиального значения. В этом случае, будет разумным объединить эти две операции в одну, а количество виртуальных пользователей сделать равным количеству пользователей, находящихся на всех складах и выполняющих данную операцию. Другими словами, количество виртуальных пользователей надо просто просуммировать.
В результате, кропотливого анализа, стало понятно, что нагрузка на систему очень плавающая. Во-первых, зависит от времени суток – днем она больше, ночью объем работы значительно меньше. Во-вторых, в течении светового дня нагрузка меняется. Склады и магазины разбросаны от Калининграда до Владивостока, соответственно, максимальная нагрузка на систему тогда, когда к ней подключены все пользователи, т.е. пик нагрузки приходится примерно в два часа дня, по новосибирскому времени. В-третьих, нагрузка зависит от понятия «сезонности». В сезон, нагрузка увеличивается, по сравнению с обычным, не сезонным, рабочим днем. В-четвертых, нагрузка в выходные уменьшается, по сравнению с нагрузкой в будний день. Соответственно меняется количество пользователей, объем создаваемых документов, количество документов и пр.
Требовалось получить обобщенную нагрузку, описав модель нагрузки.
Для описания модели нагрузки пошли несколькими путями.
Первый путь: собрать и проанализировать информацию от бизнес-подразделений, составив анкеты и проводя собеседования с экспертами от конечных пользователей. Вопросы в анкете пересекались с вопросами, перечисленными в п.п. 1-5, которые описаны выше.
Второй путь: установили мониторы в ERP системе – в базе данных. Каждый час получали срез данных о количестве пользователей, которые работают в системе, об операциях, которые выполняются в текущий момент времени, об объеме данных, с которым работают пользователи и т.п..
Мониторинг вели в течение двух-трех недель.
Результаты мониторинга сопоставили с данными полученными от бизнес-специалистов.
В итоге получили некую обобщенную нагрузку. График дневной нагрузки представлен на рисунке 1.
Рисунок 1. Изменение дневной нагрузки на ERP систему
Нулевая точка, это начало рабочего дня в Калининграде. Конечная точка – завершение рабочего дня во Владивостоке.
Видно, что до обеда нагрузка увеличивается. Пик приходится на два три часа дня, после обеда нагрузка падает. Похожая картина наблюдается и ночью, с той лишь разницей, что ночью нагрузка меньше, т.е. высота графика по оси Y будет ниже.
Есть несколько способов реализовать генератор нагрузки:
- Воспроизвести весь рабочий день, скажем от 9:00 до 18:00. Следовательно один тест будет длиться 9 часов.
- Второй вариант выделить какое-то время и воспроизвести его. Скажем, выделить один час, и воспроизвести работу ERP системы в течение часа. В этом случае, количество тестов в день может быть несколько, а модель тестирования будет гораздо гибче.
Проанализировав нагрузку на систему, мы решили сделать две модели нагрузки – воспроизвести дневную нагрузку на систему и отдельно воспроизвести ночную нагрузку. Отличие дневной от ночной в том, что днем преимущественно работают пользователи, ночью – пакетные приложения и различные отчеты.
В дневной нагрузке был выделен один час, на рисунке 1, это заштрихованная область.
Для этого часа была собрана вся необходимая информация:
- Количество операций
- Количество пользователей
- Количество обрабатываемых, создаваемых данных.
- Количество работающих автоматов, пакетных заданий.
Во время анализа нагрузки, наблюдаемой ежедневно, была замечена интересная особенность – не смотря на подключение более 1000 пользователей к системе, активно в ней работают, порядка 200 пользователей, т.е. тех кто открывают приложения, жмут на кнопки, запускаю отчеты, производят сканирование штрихов и т.д. Таких пользователей мы так и назвали «активные пользователи». Это как раз те пользователи, которые и создают реальную нагрузку в конкретный момент времени.
В итоге задача свелась к тому, чтобы воспроизвести работу этих двухсот пользователей в системе. Так как пользователи группируются по операциям, то количество скриптов, которые необходимо разработать сокращается до количества типов операций. Таких операций получилось около 30.
Все операции пользователей было реализованы через GUI-скрипты. Кроме того, для части операций были реализованы виртуальные скрипты – VU-скрипты. Недостаток времени не позволил реализовать все операции через VU-скрипты. Предполагалось, что часть VU-скриптов доработаем непосредственно в Центре Тестирования, в Париже. Некоторые операции были реализованы как SQL- процедуры. Пакетные приложения запускалась из командной строки операционной системе Solaris.
GUI и VU скрипты были реализованы с помощью встроенных в ERP систему инструментов тестирования. Описание этих инструментов я приводил в своих предыдущих статьях (http://www.software-testing.ru/about/authors/16-demchenko).
Так был реализован генератор текущей нагрузки, т.е. нагрузки наблюдаемой ежедневно. К этому генератору необходимо было добавить операции по подключаемым магазинам.
Тестовые данные
Для проведения тестирования, решили использовать несколько копий базы данных. Первая копия была полностью идентична продуктивной базе данных. Во вторую базу данных было залито сведения о 1000 магазинах.
Первую базу данных мы назвали «Эталон». Т.к. оборудование, представленное компанией Sun Microsystems было не совсем идентично тому оборудованию, на котором работала ERP система в продуктивной среде, было решено первым делом в Центре Тестирования на представленном оборудовании воспроизвести текущую нагрузку и полученные результаты считать эталонными.
На базе данных «Эталон+1000» планировали воспроизводить «Эталонную нагрузку + операции по 100 магазинам», «эталонную нагрузку + операции по 400 магазинам», и «эталонную нагрузку + операции по 1000 магазином». При этом эталонная нагрузка составляла из «Эталонная нагрузка День» и «Эталонная нагрузка Ночь».
Тестовые данные. Их необходимо было заранее передать в Benchmark Center, чтобы там подготовили все к нашему приезду. Объем базы данных составлял на тот момент порядка 2,8 Террабайт. Стояла задача - каким образом передать эти данные? Если взять в лоб перелить их на DVD диски, то потребуется порядка 800 DVD дисков – целый чемодан. Если один диск окажется ломаным, базу данных восстановить будет не возможно.
Сделать операцию экспорта\импорта базы данных, средствами Oracle, можно было, но это повлияло бы на точность полученных результатов во время тестирования, т.к. после этих операций файлы данных базы данных перестроились бы, т.е. на файловом база данных была реорганизована, поэтому этот вариант мы отбросили.
Шел 2007 год. Террабайтные USB диски только появлялись в продаже. Их появление нас выручило. Мы сначала заархивировали базу данных. Потом архивную копию залили на террабайтные USB диски. На операции архивация базы данных, копирование на USB диски было затрачено примерно две недели. Напомню, что базы было две – «Эталон» и «Эталон + 1000». Эти диски DHL-ем были отправлены во Францию. На всякий случай сделали еще копии «Эталон» и «Эталон+1000» и повезли их с собой.
На этом подготовка была завершена
Проведение тестирования
Как говорил Александр Суворов «Тяжело в учении — легко в походе, легко на учении — тяжело в походе». Время на подготовку было очень ограниченно, поэтому в учении было тяжело. Однако доучиться мы не успели, поэтому и в походе было не просто. Следующий поход по уровню сложности был гораздо выше, но прошли его, даже не вспотев, но это совсем другая история.
Время на тестирование отводилось чуть более двух недель – это очень не много. Количество тестов было запланировано порядка 15. Было предположение, что первоначального оборудования будет не достаточно. Поэтому придется увеличивать мощность тестового оборудования и проводить несколько итераций тестирования.
Первая неделя была потрачена на разворачивание ERP системы. Как я писал, задача крайне не тривиальная – необходимо было развернуть и базу данных, и сервера приложений и терминальные сервера, скомпилировать пакеты. Сложность еще заключалась в том, что ERP системы имела более 500 модификаций. Т.е. просто привезти дистрибутивы вендора было далеко не достаточно. Требовалось собрать дистрибутивы разнородных модификаций, которые были реализованы и SQL процедурами и модулями на языке C, и модулями, реализованными внутренним языком программирования NERO.
Среди решаемых проблем можно выделить следующее:
- Дистрибутив ERP оказался не полным. Из вышесказанного, не удивительно, что могли что-то забыть. Недостающие части комплексного дистрибутива оперативно получали из Новосибирска.
- Было выделено несколько мощных терминальных серверов. Установленная операционная система не видела всей физической памяти. Пришлось на всех серверах переустанавливать ОС.
- На установленной версии базы данных не работал параллелизм, который до этого не использовался, но с подключением 400 и более магазинов этот механизм необходимо было использовать. Фактически это был первый результат тестирования – необходимость перехода на новую версию базы данных Oracle. В центре тестирования мы оперативно установили новую версию базы данных. А вот в продуктивной среде надо было тщательно готовить такой переход – требовалась остановка компании на время перехода, плюс необходимость избежать ошибок, возможных при переходе с версии на версию.
- Не корректно работало часть модификаций.
- Много мелких проблем.
На разворачивание ERP было затрачено 8 дней, т.е. чуть не половина времени отведенное на тестирование.
GUI-скрипты с первого раза не заработали. Не заработали почти все VU-скрипты. После некоторого анализа поняли, что исправить ошибку с виртуальными скриптами не успеваем. Поэтому придется воспроизводить нагрузку GUI-скриптами, SQL-скриптами и процессами запущенными на серверах приложений на операционной системе Sоlaris.
С точки зрения управления тестом была не просто – тест-менеджер, который координировал работой всех тестеров – командовал, когда запускать тест, когда останавливать, чтобы работа велась одновременно. Каждый тестер отвечал за несколько десятков пользовательских сессий – порядка 40-50, на 4-5 терминальных серверах.
Каждый тест длился чуть более часа. Перед запуском теста требовалось около часа. Около часа требовалось, после проведения теста, чтобы аккуратно снять все результаты. Таким образом, на каждый тест затрачивалось по 3-4 часа, а в день проводилось по 1-2 «дневных» теста. Ночные тесты запускались ночью. А результаты работы ночных тестов снимались уже туром. После каждого теста требовалось откатить базу данных на состояние до начала теста, т.к. скрипты были жестко завязаны на тестовые данные.
После каждого теста записывалась информация о времени выполнения каждой операции, о количестве созданных документов, о приросте объема в базы данных. Кроме того, снимались показания работы оборудования – CPU, загрузка дисков, количество IOPS-ов, памяти, количество активных сессий, количество завершенных транзакций и т.д.
Итоги
После анализа полученных результатов были подведены итоги и сделаны выводы
I. БИЗНЕС-РЕЗУЛЬТАТЫ
- После подключения магазинов к ERP системе время выполнения отдельных операций вырастает. Для некоторых операций время выполнения увеличивается в 2-3 раза, по другим ключевым бизнес-операциям производительность ухудшается на 10-12 % .
- Есть ограничение по количеству подключаемых магазинов к ERP системе – не более 5 в сутки, из-за технических ограничений. Другими словами, чтобы подключить 400 магазинов потребовалось бы 80 дней непрерывной работы, т.е. 3-4 месяца.
- Прирост базы данных. Существующий на тот момент размер БД составлял 2.8 ТБ. После заливки исторических данных по 1000 магазинов размер БД увеличился на 2ТБ. Получалось, что прирост базы данных при работе в ней 400 магазинов оценивался в 900 GB в месяц (против 120 GB в настоящий момент), что потребовало покупки дополнительных дисковых массивов.
II. ТЕХНИЧЕСКИЕ РЕЗУЛЬТАТЫ
- При подключении 400 магазинов к ERP системе, произойдет существенное увеличение загрузки процессора и дисков на сервера базы данных. Имеющегося оборудования недостаточно для работы ERP с подключенными к ней 400 магазинами.
- Кроме того, необходима покупка более мощных серверов приложений, обеспечивающих импорт документов из магазинов.
Вывод к техническим результатам: для подключения 400 магазинов к ERP необходимо будет произвести обновление оборудования – параметры требуемого оборудования и ценник на него опускаю.
Кроме того, проведенное тестирование показало, что многие операции требуют оптимизацию алгоритмов. Поэтому при принятии решении о подключении магазинов к ERP системе необходимо было бы переписать большое объем функциональности.
Исходя из полученных результатов, стоимости проекта подключения магазинов к ERP системе, рисков, которые сопровождали бы реализацию данного проекта, а также ограничения по времени реализации, руководством было принято решение отказаться от выполнения этого проекта, а имеющуюся бизнес-задачу, решить другим способом.
Еще одним не маловажным результатом был его величество ОПЫТ. Были учтены и осмыслены ошибки. Дальнейшие подобные тестирования, в том же Sun Benchmark Center и IBM Центре Инновации, мы уже проводили гораздо эффективней. В частности все GUI-скрипты были заменены VU-скриптами, сначала созданные с помощью инструмента JD Edwards Virtual Editor, а затем переписаны с помощью HP Mercury LoadRunner . Эффективность использования VU-скриптов оказалась выше, а варьирование нагрузкой гораздо гибче.
Люди
Отдельно хочется отметить работу людей, участвующих в проекте. В проекте на всех этапах участвовало порядка 35 человек. Это и сотрудники компании-заказчика, и сотрудники Sun Microsystems, консультационную помощь оказывала и компания Oracle и консультанты, занимавшиеся внедрением ERP системы.
На конечной стадии проведения тестирования и оценки результатов учувствовало около 8-9 человек. С большим интересом наблюдали за ходом тестирования и полученными результатами и Sun, и Oracle, и консультанты. Глава Sun Microsystems во Франции посещал нас во время тестирования и с интересом вникал в подробности задачи.
|
