Навантажувальне тестування n8n: редакційна вправа для попередньої оцінки пропускної здатності
Практикуйте навантажувальне тестування n8n: збільшуйте синтетичний трафік вебхука, звіряйте завершені операції та визначайте відтворювану допустиму інтенсивність.
Перевірено за наведеними джерелами .
Ваше завдання з навантажувального тестування n8n
У цій редакційній вправі ваша команда має визначити найвищу перевірену інтенсивність надходження запитів до вебхука, яка відповідає вашим вимогам до затримки, збоїв і завершених операцій. Запропоновану вправу з навантажувального тестування n8n не виконували й не перевіряли на практиці. Її результат є попереднім: він стосується лише перевірених тривалості, навантаження, розгортання, залежностей і набору умов завершення.
Почніть з уже налаштованого робочого тестового екземпляра n8n на власному хостингу, ізольованого робочого процесу, робочої інсталяції k6 і контрольованого сервісу, який викликає процес. Встановлення виходить за межі цієї вправи. Використовуйте синтетичні записи та замініть зовнішні побічні ефекти заглушками. WireMock підтримує відповіді за умовами відповідності запиту та фіксовані затримки; вони не визначають квот, доступності, бізнес-ефектів реального сервісу чи повного розподілу затримок його відповідей.
На нашу думку, корисна вправа з оцінки пропускної здатності має починатися з визначення завершеної операції, адже швидке підтвердження отримання запиту — надто слабка підстава для експлуатаційного рішення.
Sources: Stubbing | WireMock, Simulating Faults | WireMock
Визначте вхідні дані та докази завершення
Перш ніж надсилати трафік, підготуйте наведені нижче вхідні дані для вправи. Запишіть встановлені версії n8n, k6 і WireMock. Граничні значення визначає ваша команда — це не універсальні рекомендації.
| Вхідні дані | Що записати перед тестуванням |
|---|---|
| Конфігурація | Версії, режим виконання, паралельність, обладнання та ревізія робочого процесу |
| Навантаження | Структура синтетичних даних запиту, інтенсивність і тривалість етапів сталого навантаження |
| Критерії прийнятності HTTP | Граничні значення затримки запитів і транспортних збоїв |
| Завершені операції | Очікуваний результат, необхідна частка завершених операцій і кінцевий строк |
| Умови зупинки | Граничні значення використання ресурсів і умови готовності |
| Докази | Журнал надісланих запитів, підтвердження та доступні результати виконання |
Публікація робочого процесу n8n реєструє його виробничий вебхук; використовуйте його URL в ізольованому розгортанні. Негайна відповідь підтверджує початок виконання, тоді як режим відповіді останнього вузла очікує завершення цього вузла. Самі по собі ні підтвердження, ні відповідь останнього вузла не доводять настання всіх очікуваних бізнес-ефектів. Вимагайте очікуваного результату, підтвердження фінальної операції та успішного результату виконання до встановленого строку завершення прийнятих операцій.
Формуйте кореляційні ідентифікатори з ідентифікатора тестового запуску, назви сценарію та k6 scenario.iterationInTest, який є унікальним у межах свого сценарію. Такий складений ідентифікатор — редакційна пропозиція. Ведіть журнал фактично надісланих запитів замість того, щоб визначати їхню кількість за найбільшим ідентифікатором, оскільки розподілені послідовності ітерацій можуть мати пропуски.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.webhook/README.md at main · n8n-io/n8n-docs · GitHub, k6/execution
Виконайте етапи зі зростанням інтенсивності трафіку
Для цієї вправи з тестування продуктивності n8n передбачте один POST-запит до вебхука на кожну ітерацію k6. k6 підтримує JSON у тілі запиту із заголовком Content-Type; явно керуйте перенаправленнями та перевіряйте відповідь цільової кінцевої точки. Виконавець constant-arrival-rate запускає ітерації незалежно від часу відповіді, доки є доступні віртуальні користувачі. Налаштуйте rate, timeUnit, duration, preAllocatedVUs і maxVUs для кожного окремого етапу сталого навантаження.
Дотримуйтеся запропонованої послідовності, зберігаючи незмінними дані запитів і припущення щодо сервісів, які викликає процес, між етапами.
- Надішліть пробний запит і перевірте передавання ідентифікатора, очікуваний результат та доступність доказів завершення.
- Проведіть етап із низькою сталою інтенсивністю надходження запитів і запишіть налаштовану та фактичну кількість надісланих запитів, затримку й HTTP-збої.
- Припиніть надсилання запитів, дайте прийнятим операціям завершитися та звірте підтвердження з результатами виконання.
- Підвищуйте інтенсивність надходження запитів лише після успішного етапу; щоразу фіксуйте готовність, спостереження щодо ресурсів і стани виконання.
- Повторіть найвищий успішний етап із тією самою конфігурацією, щоб перевірити відтворюваність.
У всіх редакціях n8n на власному хостингу /metrics за замовчуванням вимкнено; його вмикають через N8N_METRICS=true. У n8n Cloud він недоступний. Перевірте, які показники ви можете збирати, замість того, щоб припускати наявність конкретних метрик ресурсів або накопичених операцій. /healthz/readiness повертає HTTP 200, коли базу даних підключено та міграції виконано; це не доводить здатності обробляти навантаження. /healthz підтверджує доступність без перевірки стану бази даних. Для перевірок працездатності воркерів у режимі черги потрібне QUEUE_HEALTH_CHECK_ACTIVE=true.
Припиніть підвищувати навантаження, якщо порушено критерій прийнятності, погіршується готовність, досягнуто граничного використання ресурсів або генератор не може забезпечити заплановане навантаження. k6 надає exec.test.abort(), після якого teardown усе одно виконується. Зупинка генератора не скасовує операцій, уже прийнятих n8n; спостерігайте за ними до узгодженого строку їх завершення.
Sources: n8n-docs/docs/deploy/host-n8n/keep-n8n-running/monitor-n8n.md at main · n8n-io/n8n-docs · GitHub, Constant arrival rate, k6/execution, HTTP Requests
Звірте надіслані запити із завершеними операціями
Під час навантажувального тестування n8n звіряйте ідентифікатори після кожного етапу сталого навантаження. WireMock надає отримані запити через GET /__admin/requests, а кількість запитів, що відповідають заданим умовам, — через POST /__admin/requests/count. До завершення звіряння тримайте його журнал у пам’яті ввімкненим і зберігайте його цілісність; використання пам’яті цим журналом може впливати на тест. Запис у журналі підтверджує надходження запиту до заглушки, але не успішне завершення бізнес-операції.
Для дослідження результатів використовуйте фільтри виконань n8n за робочим процесом, статусом і часом початку. Видимість залежить від доступу до робочого процесу, а його видалення видаляє й історію виконань. Побудуйте процес звіряння до подавання навантаження; не припускайте, що ці інструменти автоматично пов’язують надіслані запити із завершеними операціями. На основі журналу, підтверджень і доказів виконання підготуйте запропонований нижче звіт.
Sources: View all executions | Build | n8n Docs, Verifying | WireMock
Розберіть гіпотетичне рішення щодо пропускної здатності
Цей розібраний приклад навантажувального тестування n8n використовує вигадані вхідні дані та результати вправи, а не виміряні результати n8n. Припустімо, команда обирає п’ятихвилинні етапи сталого навантаження, p95 часу HTTP-відповіді не більше ніж 500 мілісекунд, частку HTTP-збоїв не більше ніж 1 % і 100 % правильних унікальних завершень упродовж 60 секунд після припинення надсилання запитів, без дублікатів результатів. Це гіпотетичний вибір команди, а не рекомендовані граничні значення.
Припустімо, конфігурація незмінна, вебхук негайно підтверджує отримання запитів, докази збережено повністю, готовність стабільна, а граничні значення ресурсів для зупинки не перевищено. Виконуйте етапи в порядку таблиці, даючи прийнятим операціям завершитися між ними. Зараховуйте завершення лише тоді, коли для його ідентифікатора є очікуваний результат, підтвердження фінальної операції та успішний результат виконання. У таблиці затримку підтвердження відокремлено від цього набору умов завершення.
| Етап | Налаштована інтенсивність / загальна кількість | Фактично надіслані запити / інтенсивність | HTTP p95 | HTTP-збої | Завершення до кінцевого строку |
|---|---|---|---|---|---|
| A | 10/с / 3 000 | 3 000 / 10/с | 200 мс | 0 / 3 000 = 0 % | 3 000 / 3 000 = 100 % |
| B | 20/с / 6 000 | 6 000 / 20/с | 400 мс | 0 / 6 000 = 0 % | 6 000 / 6 000 = 100 % |
| Повтор B | 20/с / 6 000 | 6 000 / 20/с | 420 мс | 0 / 6 000 = 0 % | 6 000 / 6 000 = 100 % |
| C | 30/с / 9 000 | 9 000 / 30/с | 700 мс | 180 / 9 000 = 2 % | 8 820 / 9 000 = 98 % |
Обчислюйте фактичну інтенсивність як кількість фактично надісланих запитів, поділену на 300 секунд. Для етапу B ділення 6 000 на 300 дає 20 запитів за секунду; частка HTTP-збоїв становить 0, поділений на 6 000, тобто 0 %, а частка завершень — 6 000, поділені на 6 000, тобто 100 %. Повторення цього етапу також успішне. Для етапу C ділення 180 на 9 000 дає 2 % HTTP-збоїв, а ділення 8 820 на 9 000 — 98 % завершень. Його p95 у 700 мілісекунд також перевищує обрану межу.
Пропоноване рішення — попередньо визначити найвищу перевірену інтенсивність, що відповідає вимогам, на рівні 20 запитів за секунду, відтвореному під час повторення етапу B. Етап C не відповідає вимогам, хоча налаштованої інтенсивності трафіку досягнуто; припиніть підвищення навантаження. Його 180 ідентифікаторів без завершення потребують дослідження, навіть попри збіг їхньої кількості з кількістю HTTP-збоїв: однакові підсумкові числа не доводять збігу ідентифікаторів або причинного зв’язку. Інтенсивності між 20 і 30 залишаються неперевіреними, а цей приклад не встановлює експлуатаційної межі для виробничого середовища.
Завершіть рішенням із чіткими межами застосування
Завершити вправу означає задокументувати відтворюваний найвищий перевірений успішний етап сталого навантаження разом із його конфігурацією та припущеннями щодо навантаження. Якщо всі етапи успішні, повідомте лише найвищу перевірену інтенсивність, що відповідає вимогам; верхню межу ви не встановили. Якщо вправу обмежує генератор або збирання доказів, зазначте, що результат не дає змоги зробити висновок.
Пропозиція для осмислення результатів: перевірте доступність віртуальних користувачів генератора, відповідність запитів умовам заглушки, цілісність журналу та стани виконань n8n. У n8n на власному хостингу у звичайному режимі керування паралельністю виробничих виконань за замовчуванням вимкнено; N8N_CONCURRENCY_PRODUCTION_LIMIT обмежує кількість одночасних виробничих виконань і ставить надлишкові операції в чергу за принципом FIFO. Обмеження не поширюється на ручні виконання, виконання підпроцесів, процесів обробки помилок і виконання через CLI. Режим черги використовує окремий механізм керування паралельністю.
Наша практична рекомендація — змінити один чинник, який ви підозрюєте в обмеженні продуктивності, і повторити те саме навантаження, перш ніж пов’язувати з ним покращення. Сприймайте чергу або сплеск затримки як підказку для дослідження, а не як встановлену причину.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/control-concurrency.md at main · n8n-io/n8n-docs · GitHub, View all executions | Build | n8n Docs, Constant arrival rate, Verifying | WireMock
