Паралельність воркерів n8n: посібник із відтворюваного налаштування та відкату
Порівняйте паралельність воркерів n8n за контрольованого webhook-навантаження, виміряйте тиск на чергу й залежності та визначте критерії прийняття й відкату.
Перевірено за наведеними джерелами .
Що контролює паралельність воркерів n8n?
Паралельність воркерів n8n визначає, скільки завдань один воркер у режимі черги може обробляти одночасно. Для команд, що експлуатують власне розгортання, практичне питання полягає в тому, яке налаштування задовольняє вимоги їхнього навантаження, утримуючи черги, ресурси та залежності в узгоджених межах. Цей посібник пропонує відтворюваний експлуатаційний експеримент, який допоможе відповісти на це питання.
У документації n8n зазначено, що типова паралельність воркера дорівнює 10, а рекомендоване значення — 5 або більше. Це рекомендації з конфігурації, а не доказ оптимальності налаштування для ваших робочих процесів. Паралельні завдання та частота запитів — різні величини: налаштування воркера не визначає, скільки запитів до API ваші робочі процеси робитимуть за певний час.
Наведений нижче метод порівнює конфігурації за однакового заданого навантаження, відокремлює поведінку HTTP-відповідей від завершення бізнес-операцій і передбачає збереження конфігурації для відновлення. Він припускає, що режим черги вже працює; встановлення, розгортання стека моніторингу та команди розгортання для конкретних платформ виходять за його межі.
На нашу думку, експеримент із паралельністю варто проводити лише тоді, коли інший оператор зможе його пояснити та повторити. Чіткі межі вимірювання важливі не менше, ніж налаштування, які порівнюють.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/enable-queue-mode.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/control-concurrency.md at main · n8n-io/n8n-docs · GitHub, API load testing
Яке налаштування насправді визначає паралельність воркера?
У режимі черги n8n на власній інфраструктурі N8N_CONCURRENCY_PRODUCTION_LIMIT задає паралельність воркера, якщо його значення відрізняється від -1. Інакше n8n використовує прапорець --concurrency або типове значення. Не сприймайте змінну середовища як додаткове загальне обмеження для всього набору воркерів поверх прапорця кожного воркера.
Перш ніж щось змінювати, зафіксуйте встановлену версію n8n, кількість воркерів, команду запуску, перевизначення через середовище та обмеження ресурсів. Збережіть останню прийнятну конфігурацію як повну ревізію розгортання. Запис лише прапорця може не врахувати значення середовища, яке насправді визначає паралельність.
Переглянута реалізація з гілки master записує в журнал визначене значення паралельності під час запуску воркера. Ці відомості походять зі змінюваної гілки master без ідентифікатора релізу, тому перш ніж покладатися на цей вивід, зіставте реалізацію зі встановленим релізом. Таке саме обмеження щодо відповідності релізу стосується спостережень за реалізацією та схемою, використаних далі в посібнику.
Як редакційну практичну рекомендацію радимо перевіряти кожен воркер після розгортання та зберігати відповідний вивід запуску разом із записом прогону. Якщо ваш реліз не надає аналогічного виводу, перш ніж тлумачити результати порівняння, визначте інший спосіб перевірки, придатний для цього релізу.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/enable-queue-mode.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/control-concurrency.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/cli/src/commands/worker.ts at master · n8n-io/n8n · GitHub
Які передумови вже мають бути виконані?
Документація n8n зазначає, що воркерам у режимі черги потрібен доступ до Redis і бази даних n8n, а їхні ключі шифрування мають збігатися з ключем основного інстансу. Забезпечте ці передумови, перш ніж вважати зависле виконання проблемою паралельності.
Для цього експерименту використовуйте розгортання, яке вже успішно завершує типові виконання. Як підготовку радимо зберегти один завідомо робочий запит і його очікуваний бізнес-результат, перевірити доступ до експлуатаційних спостережень і визначити, хто може зупинити тест та відновити попередню конфігурацію.
Sources: Enable queue mode | Deploy | n8n Docs
Як створити відтворюване навантаження для порівняння?
Використовуйте репрезентативне навантаження на production-webhook із контрольованими вхідними даними та фіксованим розкладом надходження. Документація Grafana k6 описує сценарії constant-arrival-rate як запуск ітерацій зі сталою частотою, що відповідає такому дизайну порівняння. Одна ітерація може містити кілька запитів, тому частоту ітерацій і кількість запитів фіксуйте окремо.
Перш ніж писати перевірки, визначте контракт відповіді webhook. Grafana рекомендує перевірки відповідей і порогові значення продуктивності, але прийнятий webhook-запит може не підтверджувати завершення бізнес-операції. Визначте, який спостережуваний результат доводить, що робочий процес виконав призначену роботу.
Як варіант побудови навантаження підготуйте відтворюваний набір вхідних даних, що охоплює важливі форми запитів, і очікуваний результат для кожного випадку. Для записів використовуйте ізольоване місце призначення або інший локально узгоджений підхід і вкажіть, як ідентифікувати тестові записи та звіряти їх.
Sources: Scenarios, API load testing
Що має залишатися сталим між варіантами?
У початковому порівнянні змінюйте лише паралельність воркерів n8n. Експлуатаційний посібник постачальника, який Alex Cinovoj опублікував у 2026 році, рекомендує перевіряти зміну розміру конфігурації на однаковому навантаженні; він містить експлуатаційні поради, а не результати контрольованого порівняння. Наведений нижче запис експерименту — наш запропонований спосіб зробити цю пораду придатною для перевірки.
Заповніть цей запис до базового прогону.
| Умова | Що зафіксувати й залишити незмінним |
|---|---|
| Робочий процес | Ревізія та відповідна конфігурація |
| Вхідні дані | Випадки, пропорції та очікувані результати |
| Воркери | Кількість і обмеження ресурсів |
| Залежності | Середовище й тестові місця призначення |
| Запити | Розклад надходження та запити на ітерацію |
| Повторні спроби | Кількість спроб, паузи та пакетна обробка |
| Спостереження | Тривалість навантаження та вікно відновлення |
| Підготовка | Початковий стан черги й залежностей |
Sources: Self-Hosting n8n at Scale, A Real Runbook | Alex Cinovoj
Як перевірити, що заплановане навантаження справді надійшло?
Перевірте генератор, перш ніж пов’язувати результат із n8n. Grafana визначає dropped_iterations у k6 як ітерації, що не почалися через брак віртуальних користувачів у виконавців із заданою частотою надходження або через вичерпання дозволеного часу у виконавців із заданою кількістю ітерацій. Це сигнал від генератора навантаження.
Як редакційне правило ухвалення рішень пропонуємо позначати прогін як непереконливий, якщо запланований розклад надходження не було відтворено достатньо точно для задуманого порівняння. Зберігайте кількість запланованих, розпочатих і пропущених ітерацій та фактичних запитів і, за наявності даних, зіставляйте їх зі спостереженнями на вході.
k6 підтримує змінні середовища та теги метрик для окремих сценаріїв. Використовуйте їх для ідентифікації прогонів варіантів і груп вхідних даних, пам’ятаючи, що тег не доводить еквівалентності середовищ. Серед рекомендованих ідентифікаторів — назва прогону та ревізія робочого процесу; тлумачте їх однаково в усіх записах.
Sources: Scenarios, Built-in metrics
Що вимірювати під час кожного прогону?
Для порівняння паралельності воркерів n8n поєднуйте спостереження за чергою з результатами виконань, ресурсами контейнерів і даними про залежності. n8n надає кількість завдань, що очікують і виконуються, а також лічильники завершених і невдалих завдань для всіх воркерів. Лічильники завершених і невдалих завдань відраховуються від запуску інстансу, тому порівнюйте зміни за інтервали й враховуйте перезапуски.
Нижче наведено рекомендований набір домовленостей про вимірювання, а не вбудований звіт n8n.
| Аспект | Спостереження | Межі тлумачення |
|---|---|---|
| Коректність | Очікуваний бізнес-результат | Не підтверджується кількістю завершень |
| HTTP | Перевірки відповідей і затримка | Залежить від контракту відповіді |
| Черга | Завдання, що очікують і виконуються | Кількість не показує затримку окремого завдання |
| Завершення | Приріст завершених і невдалих завдань | Враховуйте перезапуски |
| Ресурси | CPU та пам’ять у часі | Не ізольовані для одного робочого процесу |
| Залежності | Помилки API та активність бази даних | Зіставляйте дані перед діагностикою |
Збирайте дані як під час навантаження, так і під час відновлення після припинення надходження запитів.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics.md at main · n8n-io/n8n-docs · GitHub, Enable Prometheus metrics | Deploy | n8n Docs, Runtime metrics, API load testing
Як розділити очікування в черзі, обробку воркером і час HTTP-відповіді?
Якщо вам потрібні часові вимірювання на рівні окремого виконання, використовуйте власну інструментацію. Як редакційний метод пропонуємо додавати до кожного тестового запиту кореляційний ідентифікатор і часову позначку надходження, пов’язувати цей ідентифікатор із виконанням та зіставляти спостереження початку й завершення роботи воркера з часовими позначками. Використовуйте узгоджену часову основу в усіх компонентах і повідомляйте про спостереження, які не вдалося зіставити.
Переглянута реалізація воркера з гілки master створює повідомлення про початок і завершення, що містять ідентифікатори виконання та завдання. Повідомлення про початок з’являється після початкового отримання даних виконання. Тому проміжок від надходження до початку називайте затримкою від передавання до початку: він включає накладні витрати на передавання й попередню підготовку та не є точним часом перебування в черзі Redis.
Сприймайте проміжок між записами журналу про початок і завершення як наближену тривалість обробки воркером, а не універсальну метрику тривалості виконання. Час HTTP-відповіді вимірюйте окремо на генераторі. Згенерована схема виконання містить createdAt, startedAt і stoppedAt, але сама наявність полів не визначає їхньої семантики й не підтверджує підтримуваного способу обчислення затримки в черзі.
Наведена документація не описує вбудованої гістограми затримки в черзі для окремих виконань. Якщо покриття кореляцією або узгодженість годинників недостатні, збережіть вимірювання, які можете обґрунтувати, а відповідне порівняння часових показників позначте як непереконливе.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/cli/src/scaling/job-processor.ts at master · n8n-io/n8n · GitHub, n8n/docs/generated/postgres-schema/public.execution_data.md at master · n8n-io/n8n · GitHub
Як безпечно збирати сигнали черги та ресурсів?
Для n8n на власній інфраструктурі ввімкніть метрики через N8N_METRICS=true, а метрики черги — через N8N_METRICS_INCLUDE_QUEUE_METRICS=true. n8n надає метрики черги на основних інстансах і вказує операторам відкривати доступ до кінцевої точки метрик лише внутрішнім сервісам, що споживають дані Prometheus.
Для контейнеризованих розгортань Docker описує docker stats як джерело спостережень за CPU, використанням і лімітом пам’яті та мережевим введенням-виведенням. Використовуйте незмінний спосіб збирання: у Linux Docker CLI віднімає кеш від використання пам’яті, тоді як API повідомляє загальну пам’ять і кеш окремо.
Як практику збирання радимо прив’язувати спостереження за чергою та ресурсами до часової шкали прогону й зберігати інформацію про перезапуски інстансів. Спостереження за контейнерами не визначають, яка залежність спричинила уповільнення.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics.md at main · n8n-io/n8n-docs · GitHub, Enable Prometheus metrics | Deploy | n8n Docs, Runtime metrics, docker container stats
Як виявити тиск на залежності перед збільшенням паралельності?
Аналізуйте помилки зовнішніх сервісів і спостереження за базою даних разом із поведінкою черги. Документація n8n описує відповіді сервісів про обмеження частоти запитів і застерігає, що надмірна кількість з’єднань PostgreSQL може погіршити продуктивність. Зростання черги — привід дослідити ці сигнали, перш ніж вибирати вище значення.
Як редакційну діагностичну пораду пропонуємо зіставляти початок зростання черги зі змінами в помилках API, активності бази даних і використанні ресурсів. Шукайте повторювані закономірності в порівнюваних прогонах, замість визначати причину за одним одночасним сплеском.
Ми вважаємо збільшення паралельності, яке лише переносить тиск на залежність, невдалим експлуатаційним компромісом. Рішення має спиратися на прийнятну наскрізну поведінку, включно з відновленням, а не на коротшу чергу в окремий момент.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database.md at main · n8n-io/n8n-docs · GitHub, PostgreSQL: Documentation: 18: 27.2. The Cumulative Statistics System, PostgreSQL: Documentation: 18: 27.3. Viewing Locks, n8n-docs/docs/integrations/builtin/handle-rate-limits.md at main · n8n-io/n8n-docs · GitHub
Що робити, коли запити до зовнішніх сервісів обмежуються за частотою?
n8n визначає HTTP 429 у помилках вузлів як відповідь сервісу про обмеження частоти запитів. Перегляньте ці помилки й знайдіть застосовні квоти у власній документації вашого постачальника.
Документація n8n описує Retry On Fail як додавання паузи між спробами, а Loop Over Items разом із Wait — як спосіб обробляти запити пакетами та робити паузи. Ці засоби не встановлюють узгодженого обмеження частоти для всіх воркерів.
Якщо дані вказують на потребу змінити повторні спроби або пакетну обробку, створіть окремий експеримент із політикою повторних спроб і власним базовим прогоном. Інакше спостережувана різниця поєднуватиме зміну паралельності зі зміненим характером запитів.
Sources: n8n-docs/docs/integrations/builtin/handle-rate-limits.md at main · n8n-io/n8n-docs · GitHub
Що перевіряти, коли PostgreSQL стає обмежувальним чинником?
Для з’єднань PostgreSQL у n8n на власній інфраструктурі DB_POSTGRESDB_POOL_SIZE керує кількістю паралельно відкритих з’єднань. n8n попереджає, що надмірна кількість з’єднань може погіршити продуктивність; документація не надає формули підбору розміру для конкретного навантаження.
PostgreSQL 18 описує pg_stat_activity для спостереження за поточною активністю серверних процесів, зокрема станом і запитом, а pg_locks — для перегляду поточних блокувань і дослідження конкуренції за ресурси. Використовуйте ці спостереження для дослідження бази даних у тому самому часовому вікні прогону, що й вимірювання черги.
Спостереження в PostgreSQL 18 мають обмеження: накопичувальна статистика може запізнюватися або залишатися закешованою в межах транзакції, а видимість інших сеансів залежить від привілеїв. Самі поточні блокування не доводять, що регресію спричинила паралельність. Як редакційну пораду рекомендуємо залучити відповідального за базу даних до тлумачення активності й конкуренції за ресурси, перш ніж змінювати пул.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/database.md at main · n8n-io/n8n-docs · GitHub, PostgreSQL: Documentation: 18: 27.2. The Cumulative Statistics System, PostgreSQL: Documentation: 18: 27.3. Viewing Locks
Як порівнювати варіанти та визначати критерії прийняття?
Визначте критерії прийняття до запуску варіантів. Рекомендації Grafana щодо k6 радять пов’язувати критерії успіху й невдачі з цілями рівня обслуговування або іншими важливими метриками. Ваша команда має визначити вимоги до навантаження, цільові затримки, допустимий час відновлення та бюджети ресурсів; цей посібник не пропонує універсальних порогів.
Використовуйте порожню таблицю результатів нижче як редакційний шаблон порівняння. Вносьте спостереження, а не загальне враження, і зберігайте вихідні часові ряди там, де зведення може приховати зростання накопиченої черги або короткий пік використання ресурсів.
| Спостереження | Базова конфігурація | Варіант A | Варіант B |
|---|---|---|---|
| Фактична паралельність кожного воркера | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Фактично подане навантаження | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Успішні бізнес-результати | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Затримка HTTP-відповіді | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Затримка від передавання до початку | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Наближена тривалість обробки воркером | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Відновлення черги | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| CPU | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Пам’ять | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Помилки зовнішніх сервісів | Не зафіксовано | Не зафіксовано | Не зафіксовано |
| Спостереження за базою даних | Не зафіксовано | Не зафіксовано | Не зафіксовано |
Ми рекомендуємо вибирати найменш агресивний варіант, що відповідає всім обов’язковим критеріям. Якщо базова конфігурація вже задовольняє узгоджені потреби, залишити її — цілком прийнятний результат; налаштування не зобов’язує приймати зміну.
Sources: API load testing
Як гіпотетичне порівняння приводить до прийняття рішення та відкату?
Наведений нижче розібраний приклад — гіпотетична редакційна рекомендація. Усі навантаження, пороги та спостереження тут вигадані для демонстрації процесу ухвалення рішення, а не є виміряними результатами чи рекомендованими цілями. Припустімо, команда порівнює два воркери з фактичною паралельністю 5 із тими самими двома воркерами з паралельністю 10, залишаючи незмінними встановлену версію, ревізію робочого процесу, обмеження ресурсів, пул бази даних, склад вхідних даних, повторні спроби та середовище залежностей.
Для кожного прогону заплануйте один webhook-запит на ітерацію з частотою дві ітерації на секунду протягом п’яти хвилин: 600 запитів. Виділіть ще 60 секунд на відновлення та звірте кожен очікуваний запис у місці призначення. Перед тестуванням установіть локальні критерії: усі 600 результатів коректні, немає пропущених ітерацій, p95 часу HTTP-відповіді нижче 500 мілісекунд, p95 затримки від передавання до початку нижче двох секунд, відновлення черги в межах 60 секунд, пікова пам’ять воркера нижче 75 % його ліміту, немає помилок API та спостережуваного блокування в базі даних. Таблиця показує вигадані спостереження.
| Аспект | Базова конфігурація: 5 | Варіант: 10 |
|---|---|---|
| Подані запити / пропущені ітерації | 600 / 0 | 600 / 0 |
| Коректні результати в місці призначення | 600 | 596 |
| p95 часу HTTP-відповіді | 300 мс | 280 мс |
| p95 затримки від передавання до початку | 1,5 с | 0,8 с |
| Відновлення черги | 30 с | 45 с |
| Пікова пам’ять воркера / ліміт | 55 % | 70 % |
| Помилки API | 0 | 4 відповіді HTTP 429 |
| Спостережуване блокування в базі даних | Немає | Немає |
| Рішення | Пройдено | Не пройдено |
За цими вигаданими критеріями базова конфігурація проходить перевірку, а варіант — ні, попри коротшу затримку від передавання до початку. Залиште базову конфігурацію. Перед прогоном варіанта збережіть повну ревізію базового розгортання як конфігурацію A: два воркери, --concurrency=5 і N8N_CONCURRENCY_PRODUCTION_LIMIT=-1 разом з усіма незмінними налаштуваннями. Конфігурація варіанта B використовує --concurrency=10 із тим самим значенням середовища.
Для цього прикладу заздалегідь визначте будь-яку відповідь HTTP 429 як умову негайного відкату. Коли з’явиться перша вигадана відповідь 429, припиніть надходження запитів і виконайте заплановану процедуру зупинки. Відновіть конфігурацію A через механізм розгортання команди, перевірте фактичну паралельність 5 на обох воркерах і звірте записи з невизначеним результатом. Повторіть базове навантаження; вигадані спостереження відновлення — 600 коректних результатів, нуль помилок API та відновлення черги за 30 секунд — задовольнили б критерії відновлення цього прикладу. Збережіть як запис невдалого варіанта, так і докази відновлення.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/control-concurrency.md at main · n8n-io/n8n-docs · GitHub, n8n/packages/cli/src/commands/worker.ts at master · n8n-io/n8n · GitHub, Enable queue mode | Deploy | n8n Docs
Коли прогін успішний, невдалий або непереконливий?
Відокремлюйте перевірки коректності від тестових порогів. Grafana зазначає, що невдалі перевірки k6 за замовчуванням не роблять тест невдалим і не переривають його. Явно налаштуйте потрібну поведінку визначення успіху та невдачі.
Як правило ухвалення рішення пропонуємо вважати прогін успішним лише тоді, коли фактично подане навантаження, коректність бізнес-результатів, затримки, відновлення черги, ресурси та збої залежностей відповідають заздалегідь визначеним критеріям. Вважайте його невдалим, коли коректне порівняння порушує обов’язковий критерій. Позначайте результат як непереконливий, коли навантаження відрізняються, спостережень недостатньо або генератор не витримує потрібного розкладу.
Відокремлюйте умови зупинки від остаточного прийняття. Серед рекомендованих умов зупинки — досягнення узгодженої межі помилок, неприйнятний вплив на залежності або неможливість належно спостерігати за системою. Призначте оператора, який може відреагувати на ці умови під час прогону.
Sources: Built-in metrics, API load testing
Як виконати відкат і підтвердити відновлення?
Відновіть повну попередню фактичну конфігурацію, включно з перевизначеннями через середовище, за допомогою вашого усталеного механізму розгортання. Документація n8n визначає N8N_GRACEFUL_SHUTDOWN_TIMEOUT як час, відведений активним завданням воркера на завершення перед припиненням роботи. Узгодьте загальний час, дозволений на зупинку, із цим вікном.
Docker Compose описує зупинку сервісів без видалення їхніх контейнерів і надає параметр тайм-ауту зупинки. Така поведінка зупинки не є повною процедурою оновлення конфігурації: запуск наявного зупиненого контейнера не доводить, що змінену конфігурацію застосовано.
Час, відведений на зупинку, не гарантує завершення кожного виконання або того, що зовнішні записи відбудуться рівно один раз. Включіть звіряння результатів до плану відновлення. Наведена нижче послідовність — рекомендована редакційна практика, яку слід адаптувати до вашого розгортання.
- Припиніть надходження тестових запитів, коли спрацює умова відкату.
- Виконайте заплановану процедуру зупинки та спостерігайте за поточною роботою.
- Відновіть збережену ревізію розгортання та фактичне перевизначення.
- Перевірте застосовану конфігурацію кожного воркера.
- Звірте незавершені або невизначені бізнес-результати.
- Повторіть базове навантаження та оцініть критерії відновлення.
Sources: n8n-docs/docs/deploy/host-n8n/configure-n8n/scaling/control-concurrency.md at main · n8n-io/n8n-docs · GitHub, Enable queue mode | Deploy | n8n Docs, docker compose stop
Що має містити підсумковий експлуатаційний запис?
Зберігайте разом прийняту конфігурацію, визначення навантаження, докази фактично поданого навантаження, покриття вимірюваннями, рішення про прийняття, умову відкату та спостереження відновлення. Як практику передавання відповідальності радимо зазначити відповідального та обставини, які мають спонукати до нового порівняння, наприклад зміну складу робочих процесів.
Результат обґрунтовує експлуатаційний вибір для перевіреного навантаження та середовища. Збережіть достатньо подробиць, щоб інший оператор міг повторити порівняння й оцінити, чи рішення досі підходить.
