Workflow từ 5 lên 30 phút: bottleneck ở đâu?
Runbook tìm bottleneck khi workflow n8n đột ngột chạy chậm: đo queue wait, node duration, API, dữ liệu, database, CPU, memory và xác minh sau tối ưu.
Khi một workflow từng chạy 5 phút nay mất 30 phút, đừng bắt đầu bằng cách tăng CPU hoặc tách thêm worker. Hãy xác định 25 phút phát sinh nằm ở đâu: chờ trong queue, chờ API bên ngoài, xử lý nhiều items hơn, retry/rate limit, ghi execution data, database chậm hay CPU/memory bị bão hòa. Chỉ tối ưu sau khi có bằng chứng về stage gây tăng latency.
Cách điều tra nhanh là so sánh một execution chậm với một execution tốt có input tương đương; tách queue wait khỏi execution runtime; xếp hạng node theo duration; rồi đối chiếu duration với item count, payload size, HTTP status/retry và tài nguyên hệ thống. Nếu chỉ workflow này chậm, ưu tiên node và downstream. Nếu nhiều workflow cùng chậm, ưu tiên worker, queue, database và hạ tầng. Đây là bài toán regression analysis, không phải phỏng đoán cấu hình.
Khoanh vùng
Trước tiên, xác nhận 30 phút là chạy hay là chờ
End-to-end latency và thời gian node thực thi là hai đại lượng khác nhau.
Ghi lại ít nhất bốn mốc: thời điểm trigger nhận yêu cầu, thời điểm execution được tạo, thời điểm worker bắt đầu xử lý và thời điểm hoàn tất. Trong queue mode, n8n chuyển production executions cho worker qua hàng đợi. Vì vậy job có thể xuất hiện đúng giờ nhưng bắt đầu muộn do backlog, worker thiếu capacity hoặc concurrency quá thấp. Khi đó, tối ưu một node không giải quyết được thời gian chờ trước execution.
Tạo hai chỉ số: queue_wait_seconds = worker_started_at - queued_at và run_seconds = finished_at - worker_started_at. Nếu hệ thống chưa có đủ timestamp, dùng execution history, worker logs và metric hiện có để dựng lại gần đúng. Kiểm tra theo p50, p95 và p99 thay vì chỉ nhìn một lần chạy. Một outlier 30 phút khác hoàn toàn với việc p95 tăng liên tục từ 5 lên 30 phút.
