От переводчика: сейчас многие посматривают в сторону n8n благодаря простоте и большому набору готовых интеграций. Но всех волнует вопрос — а сдюжит ли эта система с нашими данными? Поэтому разработчики сами провели нагрузочное тестирование в разных режимах и поделились своими методиками.

Вам интересно, какую нагрузку способен выдержать n8n, прежде чем он поднимет белый флаг? Мы выжали из него все соки — и результаты впечатлили.

Когда вы работаете с критически важными бизнес-процессами, вам необходимо знать свои пределы. Поэтому мы недавно провели тестирование различных вариантов развертывания n8n — имитируя высокую нагрузку и максимально используя ресурсы, чтобы выяснить, какие конфигурации показывают наилучшие результаты.

Независимо от того, управляете ли вы небольшим проектом или инжинирингом в мультинациональной компании, стресс-тестирование значительно помогает предотвратить простои, узкие места и невыполнение обязательств. Это бенчмарк-исследование и видео наглядно покажут, на что способен n8n и где он начинает давать сбои!

Испытание для ваших рабочих процессов

Мы провели стресс-тестирование n8n на двух типах инстансов AWS — C5.large и C5.4xlarge — используя как Single, так и Queue режимы n8n (многопоточная архитектура на основе очередей). Для нагрузочного тестирования мы использовали K6, для мониторинга ресурсов в реальном времени — Beszel, а рабочие процессы benchmarking от n8n — для автоматического запуска каждого сценария стресс-тестов.

Этот процесс использовал электронную таблицу для перебора различных уровней виртуальных пользователей (VUs), выполнения каждого теста и записи результатов по мере их получения. После регистрации данных мы преобразовали их в графики, которые выявили ключевые показатели производительности. Кроме того, в реальном времени мы могли наблюдать, насколько хорошо система справляется с различными нагрузками — как быстро она реагирует, насколько надежно выполняет задачи и где начинает сбоить.

Вот как мы это настроили:

Инстанс AWS C5.large состоял из:

1 vCPU
2 потоков
4 ГБ ОЗУ
пропускной способности 10 Гбит/с

Когда мы перешли на C5.4xlarge, мы добавили 16 vCPU + 32 ГБ ОЗУ.

Мы запустили три критически важных сценария тестирования:

Одиночный вебхук: один поток, запускаемый многократно
Множественные вебхуки: 10 рабочих процессов, запускаемых параллельно
Бинарные данные: загрузка и обработка больших файлов

Каждый тест масштабировался от 3 до 200 виртуальных пользователей для измерения:

Запросов в секунду
Среднего времени отклика
Процент отказов под нагрузкой

Если вы хотите настроить собственное стресс-тестирование, мы включили все необходимые инструменты в конец этой статьи, включая скрипты бенчмаркинга n8n.

Одиночный вебхук

Мы начали с малого — с одного вебхука. Это имитировало отправку вебхук-запроса на сервер n8n и получение обратно ответа о том, что вызов был получен. Это был всего один рабочий процесс и одна конечная точка, с постепенным наращиванием трафика, чтобы увидеть, насколько можно нагрузить один экземпляр n8n.

При использовании экземпляра AWS C5.large развертывание в Single-режиме n8n показало удивительно хорошую устойчивость к нагрузке, как видно из приведенной ниже таблицы сравнения. Хотя этот экземпляр выдержал до 100 виртуальных пользователей, при достижении 200 ВУ мы уперлись в потолок для однопоточной настройки: время отклика достигло 12 секунд, а уровень отказов составил 1%.

Когда мы включили Queue mode — более масштабируемую архитектуру n8n, которая разделяет прием вебхуков и выполнение рабочих процессов, — производительность подскочила до 72 запросов в секунду, задержка снизилась менее чем до трех секунд, и система обработала 200 виртуальных пользователей с нулевым количеством сбоев.

При переходе на C5.4xlarge (16 vCPU, 32 ГБ ОЗУ) мы наблюдали впечатляющий рост производительности. В однопоточном режиме (Single mode) пропускная способность незначительно увеличилась до 16,2 запросов в секунду с умеренным улучшением задержек.

Однако именно режим очереди (Queue mode) показал выдающийся результат. Мы достигли стабильных 162 запросов в секунду и поддерживали эту нагрузку при полных 200 виртуальных пользователях, с задержкой менее 1,2 секунды и нулевым количеством сбоев. Это десятикратное увеличение пропускной способности, достигнутое просто за счет вертикального масштабирования и выбора правильной архитектуры.

Множественные вебхуки

Для следующего теста мы хотели имитировать многозадачность корпоративного уровня, чтобы лучше отразить реальные развертывания n8n, поэтому мы настроили 10 различных рабочих процессов, каждый из которых запускался собственным вебхуком.

На C5.large в однопоточном режиме (Single mode) производительность быстро ухудшилась. При 50 виртуальных пользователях время отклика подскочило выше 14 секунд с 11% уровнем отказов. При 100 ВУ задержка достигла 24 секунд с 21% отказов. А при 200 ВУ уровень отказов достиг 38%, а время отклика растянулось до 34 секунд — по сути, это был коллапс.

Переход на режим очереди (Queue mode) изменил всё. Он поддерживал стабильные 74 запроса в секунду от 3 до 200 виртуальных пользователей, с задержкой в допустимых пределах и 0% уровнем отказов. То же железо — совершенно другой результат.

Вновь инстанс C5.4xlarge вывел производительность на новый ��ровень. В однопоточном режиме (Single mode) он достиг пика в 23 запроса в секунду при 31% уровне отказов.

Однако в режиме очереди (Queue mode) мы достигли и стабильно поддерживали 162 запроса в секунду при любой нагрузке с нулевым количеством сбоев. Даже при максимальной нагрузке задержка оставалась на уровне около 5,8 секунд.

Для многозадачности в больших масштабах требуются более мощные ресурсы, и режим очереди (Queue mode) полностью оправдывает себя.

Загрузка бинарных файлов

Наконец, мы решили протестировать наиболее требовательные к оперативной памяти и дисковым операциям задачи, настроив бенчмарк для работы с бинарными данными — рабочими процессами, которые обрабатывают загрузку больших файлов: изображений, PDF-документов и медиафайлов.

На инстансе C5.large в однопоточном режиме (Single mode) проблемы начались почти сразу. Уже при трех виртуальных пользователях мы получили всего 3 запроса в секунду. При 200 виртуальных пользователях время отклика катастрофически выросло, а 74% запросов завершились ошибкой. Это не просто замедление — это полный операционный сбой.

Режим очереди (Queue mode) показал немного лучшую устойчивость, отодвинув момент сбоя. Однако к отметке в 200 виртуальных пользователей и он перестал справляться, показав 87% ошибок и неполную обработку передаваемых данных.

Затем мы перешли на C5.4xlarge. На этом более мощном инстансе в однопоточном режиме (Single mode) мы достигли 4,6 запросов в секунду, сократили время отклика на треть и снизили процент отказов с 74% до всего 11%. Значительно лучше, но все же не идеально.

Затем в режиме очереди (Queue mode) мы достигли пика в 5,2 запроса в секунду и, что самое важное, сохранили 0% уровень отказов в течение всего теста. Каждый крупный файл был успешно получен, обработан и на него был отправлен ответ. Этот тест ясно показал: дело не только в архитектуре. Рабочие процессы с интенсивной работой с бинарными данными требуют значительных ресурсов CPU, оперативной памяти и пропускной способности диска.

Ключевые выводы

Итак, что же показали нам все эти тесты?

Режим очереди (Queue mode) не опционален. Это первый шаг к реальной масштабируемости. Даже на базовом оборудовании он значительно повышает производительность при минимальных настройках.

Аппаратное обеспечение имеет значение. Переход на C5.4xlarge более чем удваивает пропускную способность, сокращает задержки вдвое и полностью устраняет количество сбоев.

Бинарные данные ломают всё — если вы не готовы. Вам потребуется больше оперативной памяти, более быстрый диск, распределенное хранилище (например, S3) и параллельные воркеры для управления всем этим.

Если вы автоматизируете работу внутренних команд, бэкенд-систем или клиентских приложений, не ждите, пока узкие места заставят вас делать апгрейд. Заранее планируйте масштабирование. Используйте Queue mode для разделения приема запросов и их обработки, масштабируйтесь горизонтально с помощью воркеров для параллельной обработки и подбирайте оборудование в соответствии с вашей рабочей нагрузкой. Простым потоком нужно меньше, а для бинарных данных и многозадачности нужно больше. n8n создан для масштабирования, но, как и любой двигатель, ему нужно правильное топливо и правильная трасса, чтобы достичь полной мощности.

Какой тест вы хотите воспроизвести?

Подписывайтесь на канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.

Тест на масштабируемость n8n