Тестуємо продуктивність Ultima Businessware

Вітаю, читач!
У цій статті я розповім, як ми тестували продуктивність нашої платформи.

Тестування продуктивності ми планували провести з самого початку розробки нової версії системи, оскільки реалізували безліч оптимізацій. Однак, відкладали через велику зайнятість, поки в один прекрасний день мені не повідомили, що вдалося домовитися про тестування на 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, поколоночное зберігання і деякими іншими.
Про результати розповімо в нашому блозі. Не перемикайтеся.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.