اگر اجرای چند workflow همزمان باعث کندی n8n شده، اولین کار خرید منابع بیشتر نیست. باید معلوم کنید زمان در صف می‌گذرد، داخل یک نود مصرف می‌شود یا صرف انتظار پاسخ یک API می‌شود. Queue Mode برای تقسیم اجرای workflow میان workerهاست؛ یک درخواست کند به مدل هوش مصنوعی را به‌تنهایی سریع نمی‌کند.
در این راهنما، ابتدا علت کندی را پیدا می‌کنیم و بعد معماری چندسرویسی، تنظیمات پایه، آزمون انتقال و کنترل هزینه را بررسی می‌کنیم. برای شروع ساده می‌توانید هاست n8n پاستا را بررسی کنید. راه‌اندازی چند worker به امکانات شبکه، فرمان اجرا و سرویس‌های جانبی نیاز دارد و نباید آن را قابلیت پیشفرض هر پلن فرض کنید.
کندی n8n را به سه مسئله جدا تقسیم کنید
زمان دریافت webhook تا شروع اجرای workflow، زمان انتظار است. زمان شروع تا پایان، مدت اجرای واقعی است. زمان پاسخ به کاربر نیز ممکن است با هر دو متفاوت باشد؛ مثلاً workflow فوراً رسید دریافت بدهد و پردازش را بعداً تمام کند. این سه عدد را برای یک نمونه واقعی ثبت کنید، نه برای یک اجرای دستی با داده بسیار کوچک.
اگر بیشتر زمان داخل نود HTTP Request می‌گذرد، لاگ سرویس مقصد و محدودیت نرخ آن را بررسی کنید. اگر CPU بالا و زمان پردازش محلی زیاد است، تبدیل داده یا کد داخل workflow را بهینه کنید. اگر تعداد اجراهای منتظر بالا می‌رود ولی workerها سالم‌اند، ظرفیت پردازش و هم‌زمانی را بررسی کنید. افزایش تعداد worker پیش از این تشخیص، فقط هزینه و تعداد تماس با سرویس مقصد را زیاد میکند.
Queue Mode چه معماری‌ای دارد؟
طبق مستندات رسمی n8n، فرایند اصلی کار را دریافت میکند، Redis صف را نگه می‌دارد و workerها اجرا را انجام می‌دهند. داده‌های پایدار در دیتابیس قرار می‌گیرند. همه اجزا باید به Redis و PostgreSQL مشترک دسترسی داشته باشند و کلید رمزگذاری credentialها یکسان باشد.
در طراحی اولیه، یک فرایند اصلی و یک worker کافی است تا مسیر انتقال را آزمایش کنید. افزودن worker دوم باید بعد از اندازه‌گیری انجام شود. برای هر جزء نام مشخص، مالک تنظیمات و مسیر پایش داشته باشید. Redis را صرفاً یک cache قابل حذف تلقی نکنید؛ از دسترس خارج‌شدن آن می‌تواند اجرای کارهای صف را مختل کند.
قبل از مهاجرت چه چیزهایی آماده کنیم؟
- نسخه یکسان و مشخص n8n برای فرایند اصلی و workerها؛ از برچسب متغیر latest برای انتقال حساس استفاده نکنید.
- نسخه پشتیبان قابل بازیابی از دیتابیس و نگهداری امن کلید رمزگذاری فعلی.
- دسترسی شبکه خصوصی به دیتابیس و Redis؛ بدون بازکردن عمومی پورت‌ها.
- فهرست workflowهای فعال، webhookها، زمان‌بندی‌ها و عملیات دارای اثر جانبی.
- محیط آزمایش با داده ساختگی و دسترسی جدا از حساب‌های واقعی مشتری.
اگر اکنون از SQLite استفاده می‌کنید، انتقال دیتابیس را به‌عنوان یک مرحله مستقل انجام دهید. صرف تغییر یک متغیر، داده را منتقل نمی‌کند. قبل از رفتن به صف، بازشدن workflowها و امکان استفاده از credentialها را روی دیتابیس مقصد بررسی کنید. جایگزین‌کردن کلید رمزگذاری قدیمی با یک کلید تازه ممکن است دسترسی به credentialهای موجود را از بین ببرد.