Мільйони документів. Кава — одна.
На складі вже чекають машини. Оператори проводять відвантаження, інша зміна приймає товар, інтернет-магазин передає нові замовлення, а фінансовий відділ запускає звіт за місяць. І саме в цей момент працівник натискає «Провести документ». Скільки він чекатиме, перш ніж зможе оформити наступне відвантаження?
Під час обговорення майбутніх впроваджень нам озвучували різні вимоги: 100 мільйонів рухів товару на місяць, 100 тисяч рядків на день і тисячі користувачів, які працюють одночасно. Кожна цифра описує іншу сторону навантаження. Місячний обсяг показує, як швидко зростає історія операцій. Денний потік допомагає оцінити інтенсивність обробки. Кількість одночасних користувачів потрібна, щоб зрозуміти, які дії система має виконувати паралельно.
У K2 ми не чекаємо, поки клієнти дійдуть до таких обсягів. Заздалегідь генеруємо великі набори даних, відтворюємо робочі сценарії в тестовому середовищі й вимірюємо, як система реагує. Для цього в K2 ERP є генератор тестових даних. У відео показуємо його роботу на невеликому прикладі, а в масштабних тестах використовуємо мільйони товарних позицій, десятки мільйонів документів і тисячі паралельних процесів генерації з записом у базу даних.
Чому місячного обсягу замало для оцінки швидкодії
Уявімо два підприємства, кожне з яких обробляє сто тисяч рядків на день. У першого документи надходять відносно рівномірно. У другого більшість замовлень приходить незадовго до відправлення машин. У підсумковому звіті обсяг однаковий, але в другому випадку система має виконати значно більше роботи за короткий час.
Так само важливо, які саме операції виконуються одночасно. Пошук товару за артикулом, імпорт замовлень і проведення відвантаження створюють різне навантаження. Складський документ із кількома позиціями й документ із сотнями рядків також потребують різного обсягу роботи. Під час проведення, залежно від типу операції, система може перевіряти доступність товару, формувати рухи та оновлювати пов’язані дані.
Тому для тесту потрібні параметри робочого процесу. Скільки замовлень надходить у пікові п’ятнадцять хвилин? Скільки позицій містить типовий документ? Скільки складів одночасно працюють з однією номенклатурою? Чи запускається звітність, поки триває відвантаження? Від цих відповідей залежить, яке навантаження відтворювати.
Що відбувається між кліком у браузері та відповіддю системи
У вебдодатку натискання кнопки запускає цілий ланцюжок. Браузер надсилає запит. Сервер приймає його, перевіряє права доступу та виконує бізнес-логіку. Якщо потрібна робота з даними, запит може чекати на вільне з’єднання з базою. Далі база читає або записує дані, сервер формує відповідь, а браузер отримує її та оновлює екран.
Затримка може виникнути в будь-якій частині цього ланцюжка. База вже повернула список товарів, але браузер довго будує велику таблицю. Або інтерфейс готовий показати результат, але запит ще чекає на завершення іншої транзакції. Іноді час витрачається на саму передачу великого обсягу даних до робочого місця. Тому для вебдодатка окремо вимірюють швидкість серверного запиту й час, за який користувач фактично отримує результат у браузері.
Є ще одна особливість корпоративного вебдодатка. Оператор складу, працівник офісу й зовнішня інтеграція можуть одночасно звертатися до спільних серверних ресурсів. Масовий імпорт, який добре проходить окремо, може змінити швидкість пошуку та проведення документів під час робочої зміни. Тому ми поступово переходимо від перевірки окремих функцій до сценаріїв, у яких кілька операцій виконуються разом.
Що змінюється, коли база даних виростає
Запит, який швидко працював у демо, може отримати інший план виконання
У невеликій базі навіть перегляд усієї таблиці може пройти швидко. Коли рядків мільйони, значення має те, скільки даних PostgreSQL повинен прочитати, як він з’єднує таблиці та де сортує результат. Для пошуку одного артикулу індекс може суттєво зменшити обсяг читання. Для звіту, який охоплює значну частину таблиці, послідовне читання іноді вигідніше. Індекси також займають місце й потребують додаткової роботи під час змін даних.
Для діагностики в PostgreSQL можна використати EXPLAIN, а в контрольованому середовищі — EXPLAIN (ANALYZE, BUFFERS). План показує, які операції виконує база, а фактичне виконання допомагає побачити, де витрачається час і наскільки оцінена кількість рядків відрізняється від фактичної. Це дає змогу перевірити конкретну гіпотезу. Наприклад, чи сповільнює список документів сам фільтр, сортування результату або з’єднання з довідником.
Одночасні записи можуть чекати один на одного
Уявімо, що два відвантаження одночасно резервують той самий товар з однієї комірки. Якщо обидві транзакції змінюють той самий запис, одна може чекати на завершення іншої. Під час піку такі очікування накопичуються. Користувач бачить, що документ довго проводиться, хоча сервер ще має запас процесорної потужності. У цьому сценарії важливо перевірити і час відповіді, і результат операції. Наприклад, чи збігається залишок після паралельних резервувань.
Саме тому структура тестових даних має значення. Якщо генератор рівномірно розподілив операції між усіма товарами, тест може пропустити ситуацію, коли більшість користувачів працює з невеликою групою популярних позицій. Для реалістичного сценарію потрібні активні та рідко використовувані товари, великі й малі склади, документи різного розміру, а також періоди, на які припадає найбільший потік операцій.
Масовий запис навантажує диски й журнал транзакцій
Під час запису PostgreSQL працює з даними, індексами та журналом попереднього запису, відомим як WAL. Коли багато процесів одночасно вносять зміни, час відповіді може залежати від швидкості дискових операцій і синхронізації журналу. Контрольні точки, під час яких база записує змінені сторінки на диск, теж створюють навантаження. Тому під час тесту важливо зіставляти затримки операцій із тим, що в цей момент відбувається на сервері бази даних.
База після кількох років роботи відрізняється від щойно наповненої
У PostgreSQL оновлення й видалення залишають старі версії рядків, які з часом прибирає VACUUM. Статистику про дані, потрібну планувальнику запитів, оновлює ANALYZE. Якщо в робочій системі активно змінюють документи, оновлюють залишки й регулярно завантажують нові дані, поведінка бази протягом тривалої зміни може відрізнятися від результату короткого тесту відразу після генерації. Тривалі сценарії допомагають побачити, як робоче навантаження співіснує з фоновим обслуговуванням бази.
Великі списки та звіти вимагають окремої перевірки
Користувач може бачити лише п’ятдесят документів на екрані, а база при цьому обробляє значно більше рядків, щоб відфільтрувати й відсортувати результат. Під час глибокої пагінації з OFFSET пропущені рядки все одно потрібно обчислити на сервері. Для деяких списків можна розглянути перехід за останнім видимим записом, а для таблиць з історією — поділ на секції за періодами, якщо запити справді відбирають дані за періодом. Користь кожної зміни перевіряють на типових фільтрах, звітах і розподілі даних конкретної системи.
Як ускладнюємо сценарії тестування
Спочатку визначаємо, що саме потрібно перевірити. Генератор допомагає підготувати каталог, історію документів і потік запису. Далі сценарій може зосередитися на окремій ділянці або пройти весь шлях від дії користувача до отримання результату.
- Окрема операція. Вимірюємо пошук у довіднику, відкриття списку, проведення документа або формування звіту. Так простіше локалізувати причину затримки.
- Змішане навантаження. Одні користувачі оформлюють приймання, інші проводять відвантаження, інтеграція передає замовлення, а керівник відкриває залишки. Вимірюємо, як ці дії впливають одна на одну.
- Раптовий пік. Різко збільшуємо потік операцій. Перевіряємо, чи зростає черга, де з’являються тайм-аути та як швидко система повертається до звичайного режиму після піку.
- Тривала робота. Утримуємо навантаження довше, щоб побачити, чи накопичуються черги, чи змінюється швидкість з часом і як на неї впливають фонові процеси.
Окремо визначаємо, звідки надходить потік. Працівник зазвичай чекає, поки відкриється документ, перш ніж зробити наступну дію. Зовнішня інтеграція може надсилати нові замовлення з тією самою інтенсивністю, навіть коли попередні ще обробляються. Якщо відтворити такий потік сценарієм, який завжди чекає на попередню відповідь, тест сам зменшить навантаження в момент сповільнення. Через це можна пропустити момент, коли в реальній роботі почала б рости черга.
Що вимірюємо і як читаємо результат
Середній час відповіді може виглядати прийнятно, навіть коли частина працівників регулярно чекає довше. Тому дивимося на розподіл часу. Якщо p95 проведення документа дорівнює двом секундам, приблизно 95 відсотків виміряних операцій завершилися за дві секунди або швидше. Решта тривали довше. Це приклад читання метрики. Прийнятні межі визначаються окремо для кожної операції та підприємства.
Окрім часу відповіді, важливо бачити, скільки успішно завершених операцій система обробляє за хвилину, скільки є помилок і тайм-аутів, чи ростуть черги та який ресурс обмежує роботу. Для діагностики PostgreSQL можна зіставити дані pg_stat_statements про SQL-запити зі станами сесій і подіями очікування в pg_stat_activity. Так легше розрізнити запит, який сам виконується довго, і запит, який більшу частину часу чекає на ресурс або іншу транзакцію.
Для ERP швидкість перевіряємо разом із коректністю операцій. Якщо запит на проведення не отримав відповіді вчасно, працівник або інтеграція можуть повторити його. Тест має показати, що за таких умов відвантаження не задвоїться, а залишки узгоджуватимуться з документами. Також важливо спостерігати за самим потоком повторних запитів. Під час перевантаження неконтрольовані повтори здатні збільшувати чергу й посилювати затримки.
Що саме показано у відео
У відео ми навмисно беремо невеликий обсяг, щоб за один запуск показати весь процес. У генераторі є два розділи.
- Довідники. Генеруємо номенклатуру, контрагентів, місця розташування та контейнери. Для номенклатури задаємо кількість гілок, кількість товарів і рівень вкладеності.
- Документи. У показаній версії генерація документів доступна для K2 WMS. Можна вибрати типи документів із продажів, закупівель і складських операцій, задати кількість і за потреби ввімкнути проведення.
У демонстраційному запуску генератор записав 630 документів за 80 секунд. Це вимір часу підготовки даних у конкретному запуску. Після завершення ми відкриваємо K2 WMS і перевіряємо, що створені записи, зокрема договори, з’явилися в робочих списках.
У масштабних тестах той самий підхід дає змогу підготувати базу з мільйонами SKU та десятками мільйонів документів. Тисячі паралельних процесів генерації використовуємо для перевірки одночасного запису в базу. Для перевірки роботи користувачів потрібен окремий сценарій із конкретними діями, ролями та темпом роботи.
Чому це важливо для великих компаній
Для великого підприємства навіть невелика затримка на операції, яку повторюють сотні разів за зміну, впливає на пропускну здатність команди. Наприклад, додаткові три секунди на кожному з тисячі документів дають 50 хвилин сукупного очікування. Якщо затримки виникають саме перед відправленням машин, наслідок видно вже на складі. Документи накопичуються, а наступні операції чекають на завершення попередніх.
Результат навантажувального тесту допомагає ухвалити конкретні рішення до впровадження. Чи можна запускати великий звіт під час відвантаження? Як швидко обробляється імпорт після піку замовлень? Де треба оптимізувати проведення документа, а де обмеження виникає через дискову підсистему або кількість доступних з’єднань? Після зміни повторюємо той самий сценарій на порівнюваних даних і конфігурації, щоб побачити, що саме дало ефект.
Якщо ви плануєте впровадження ERP або WMS, розкажіть нам, скільки документів обробляєте за зміну, скільки людей працює в пікову годину й які операції не можуть чекати. На цих параметрах можна побудувати сценарій для вашого підприємства та заздалегідь виміряти швидкість критичних операцій.