n8n Performans Testi Öncesi Hangi Veriler Toplanmalı?

n8n üzerinde çalışan otomasyonlar büyüdükçe performans sorunlarını yalnızca “yavaş çalışıyor” ifadesiyle değerlendirmek yeterli olmaz. Sağlıklı bir test planı hazırlamak için önce mevcut iş yükünü, sistem kaynaklarını, veri hacmini ve hata davranışlarını ölçülebilir hale getirmek gerekir. Bu nedenle n8n performans testi öncesinde toplanacak veriler, testin doğruluğunu ve alınacak teknik kararların kalitesini doğrudan etkiler.

Mevcut n8n mimarisi ve çalışma modeli

İlk adım, n8n’in nasıl konumlandırıldığını netleştirmektir. Tek sunuculu kurulum, Docker, Kubernetes, queue mode, worker mimarisi veya managed servis kullanımı performans testinin kapsamını değiştirir. Özellikle queue mode kullanılan yapılarda ana n8n instance, worker sayısı, Redis ve veritabanı ilişkisi ayrı ayrı değerlendirilmelidir.

Bu aşamada şu bilgiler kayıt altına alınmalıdır:

• n8n sürümü ve kurulum tipi
• Worker sayısı ve eş zamanlı çalıştırma kapasitesi
• CPU, RAM, disk tipi ve ağ kapasitesi
• PostgreSQL, Redis veya harici servislerin konumu
• Ortam değişkenleri ve concurrency ayarları

Sık yapılan hata, yalnızca n8n sunucusuna odaklanıp veritabanı veya Redis gecikmelerini göz ardı etmektir. Oysa workflow geçmişi, execution kayıtları ve queue davranışı çoğu zaman performansın belirleyici noktasıdır.

Workflow envanteri ve kritik süreçler

Test edilecek ortamda kaç workflow olduğu kadar, hangilerinin iş açısından kritik olduğu da bilinmelidir. Her workflow aynı ağırlıkta değildir; bazıları basit veri aktarımı yaparken bazıları yoğun API çağrısı, dosya işleme veya koşullu dallanma içerebilir.

Toplanması gereken workflow verileri

• Aktif workflow sayısı
• Her workflow için node sayısı ve node tipleri
• Tetikleyici türleri: webhook, cron, manual, queue, event tabanlı akışlar
• Ortalama ve maksimum çalışma süresi
• Günlük, saatlik ve pik execution sayısı
• Başarılı, başarısız ve yeniden denenmiş işlem oranları

Özellikle webhook ile tetiklenen akışlarda pik zamanların ayrı incelenmesi gerekir. Ortalama değerler sakin görünse bile kampanya, entegrasyon yoğunluğu veya toplu veri aktarımı sırasında sistem davranışı tamamen değişebilir.

Veri hacmi ve payload özellikleri

Performans testlerinde yalnızca istek sayısını artırmak yanıltıcı olabilir. n8n’de payload boyutu, işlenen kayıt sayısı ve node’lar arasında taşınan veri miktarı doğrudan bellek kullanımını etkiler. Küçük JSON verileriyle yapılan test, gerçek hayattaki büyük dosya veya binlerce satırlık kayıt işleme senaryosunu temsil etmeyebilir.

Bu nedenle test öncesinde ortalama ve maksimum payload boyutu, batch büyüklüğü, dosya işleme gereksinimleri ve binary data kullanım şekli belirlenmelidir. Binary verinin dosya sisteminde mi, veritabanında mı yoksa harici depolamada mı tutulduğu da ayrıca not edilmelidir.

Bağımlı sistemler ve API limitleri

n8n çoğunlukla tek başına çalışan bir sistem değil, farklı servisleri birbirine bağlayan bir orkestrasyon katmanıdır. Bu nedenle performans testinde yalnızca n8n’in tepkisi değil, bağlı sistemlerin sınırları da dikkate alınmalıdır.

Toplanması gereken dış bağımlılık verileri şunlardır:

• API rate limit değerleri
• Ortalama ve maksimum yanıt süreleri
• Zaman aşımı ayarları
• Kimlik doğrulama yenileme süreleri
• Harici servislerdeki hata kodları ve kısıtlar

Bir API dakikada 100 istek kabul ediyorsa, n8n tarafında 500 eş zamanlı işlem simüle etmek gerçekçi bir test üretmez. Bu tür durumlarda test senaryosu, dış servis limitleriyle uyumlu tasarlanmalı veya mock servislerle ayrıştırılmış ölçüm yapılmalıdır.

Veritabanı ve execution geçmişi

n8n performansında veritabanı önemli bir rol oynar. Execution kayıtlarının ne kadar süre saklandığı, tablo boyutları, indeks durumu ve temizleme politikası test sonuçlarını etkileyebilir. Büyük execution tabloları, özellikle arayüzde geçmiş kayıtların görüntülenmesi veya yoğun yazma işlemlerinde gecikme yaratabilir.

n8n performans testi öncesinde veritabanı CPU kullanımı, bağlantı sayısı, yavaş sorgular, disk I/O ve tablo büyüklükleri izlenmelidir. Test ortamı üretimden kopyalanıyorsa kişisel verilerin maskelenmesi ve gereksiz execution geçmişinin senaryo dışında bırakılması güvenlik açısından önemlidir.

İzleme metrikleri ve başarı kriterleri

Testin anlamlı olması için hangi değerin kabul edilebilir olduğu baştan tanımlanmalıdır. “Daha hızlı olmalı” yerine ölçülebilir hedefler kullanılmalıdır. Örneğin webhook yanıt süresi 500 ms altında kalmalı, 1.000 execution içinde hata oranı yüzde 1’i geçmemeli veya worker CPU kullanımı belirli eşiğin altında olmalıdır.

Pratik başarı kriterleri

• Ortalama, p95 ve p99 yanıt süreleri
• Saniye veya dakika başına tamamlanan execution sayısı
• CPU, RAM, disk ve ağ kullanımı
• Queue bekleme süresi
• Timeout, retry ve failed execution oranı
• Veritabanı bağlantı havuzu kullanımı

Yalnızca ortalama yanıt süresine bakmak risklidir. Kullanıcıların veya bağlı sistemlerin yaşadığı sorunlar çoğunlukla p95 ve p99 gibi uç değerlerde görünür. Bu nedenle performans raporlarında yüzdelik dilimler mutlaka yer almalıdır.

Test senaryosu için kontrol listesi

Test başlamadan önce canlıya benzeyen ama kontrollü bir veri seti hazırlanmalıdır. Workflow’lar, payload örnekleri, tetikleme sıklıkları ve dış servis davranışları belgelenmelidir. Böylece aynı test daha sonra tekrarlandığında iyileştirme etkisi sağlıklı biçimde karşılaştırılabilir.

Uygulamada en güvenli yaklaşım, önce mevcut üretim davranışını ölçmek, ardından küçük yük artışlarıyla sistemi gözlemlemektir. Ani ve yüksek yük testleri, özellikle paylaşımlı veritabanı veya gerçek API entegrasyonları kullanılıyorsa gereksiz kesintilere neden olabilir. Test planı; ölçüm aralığı, geri dönüş adımları, sorumlu ekipler ve izlenecek panellerle birlikte hazırlanmalıdır.

Doğru veri setiyle yapılan bir performans çalışması, yalnızca darboğazları göstermekle kalmaz; worker ölçekleme, execution temizleme, queue ayarları ve altyapı kapasitesi için daha isabetli karar alınmasını sağlar.