Gateway Performans Ayarlama
Genel Bakış
Gateway performansı birçok faktöre bağlıdır:
- Donanım kaynakları: CPU core sayısı, bellek miktarı
- Trafik profili: Eşzamanlı istek sayısı, istek boyutu, SSE/streaming kullanımı
- Politika karmaşıklığı: Uygulanan politikaların sayısı ve ağırlığı (örneğin Content Filtering gibi CPU-yoğun politikalar)
- Backend yanıt süresi: Hedef servisin gecikme profili
Tuning yaklaşımı — öncelik sırası:
- Otomatik profil — Çoğu ortam için yeterlidir, müdahale gerekmez
- Tier önerileri — Kaynak boyutuna göre hazır parametre setleri (bu sayfa)
- Manuel ayar — Yük testi sonuçlarına göre ince ayar
Tier Bazlı Önerilen Ayarlar
Aşağıdaki tablolar, farklı donanım profilleri için önerilen Gateway Worker ayarlarını göstermektedir. Bu değerler, üretim öncesi yük testleri ile doğrulanmalıdır.
Tier önerileri async executor boyutunu içermez. Varsayılan yolda çekirdek 64'tür. Ayrım Async Executor bölümündedir.
Tier 1 — 2 Core / 2 GB RAM
Düşük trafikli ortamlar, geliştirme ve PoC senaryoları için uygundur.
| Parametre | Önerilen Değer |
|---|---|
tuneIoThreads | 2 |
tuneWorkerThreads | 512 |
tuneWorkerMaxThreads | 1024 |
tuneRoutingConnectionPoolMaxConnectionTotal | 2048 |
Tier 1 Ortam Değişken Bloğu Örneği:
tuneIoThreads=2
tuneWorkerThreads=512
tuneWorkerMaxThreads=1024
tuneRoutingConnectionPoolMaxConnectionTotal=2048
Tier 2 — 4 Core / 4 GB RAM
Orta ölçekli üretim ortamları için önerilir. Çoğu kurulum için dengeli bir başlangıç noktasıdır.
| Parametre | Önerilen Değer |
|---|---|
tuneIoThreads | 4 |
tuneWorkerThreads | 1024 |
tuneWorkerMaxThreads | 2048 |
tuneRoutingConnectionPoolMaxConnectionTotal | 4096 |
Tier 2 Ortam Değişken Bloğu Örneği:
tuneIoThreads=4
tuneWorkerThreads=1024
tuneWorkerMaxThreads=2048
tuneRoutingConnectionPoolMaxConnectionTotal=4096
Tier 3 — 8 Core / 8 GB RAM
Yüksek trafikli üretim ortamları için önerilir.
| Parametre | Önerilen Değer |
|---|---|
tuneIoThreads | 8 |
tuneWorkerThreads | 2048 |
tuneWorkerMaxThreads | 4096 |
tuneRoutingConnectionPoolMaxConnectionTotal | 8192 |
Tier 3 Ortam Değişken Bloğu Örneği:
tuneIoThreads=8
tuneWorkerThreads=2048
tuneWorkerMaxThreads=4096
tuneRoutingConnectionPoolMaxConnectionTotal=8192
JVM Parametreleri: Heap, direct memory ve metaspace değerleri container bellek limitine göre otomatik belirlenir (JAVA_OPTS eklemeye gerek yoktur). JAVA_OPTS içindeki heap ayarları jvmOverride=true tanımlanmadıkça uygulanmaz. Kademe tabloları ve manuel GC yapılandırması için JVM Garbage Collector Ayarlama sayfasına bakın.
Thread Tuning
Worker Threads
Worker thread'ler, gelen HTTP isteklerini işleyen temel thread pool'dur.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneWorkerThreads | CPU core sayısı × 8 | Minimum Worker thread sayısı — sunucu başlangıcında oluşturulan thread'ler |
tuneWorkerMaxThreads | CPU core sayısı × 16 | Maksimum Worker thread sayısı — yük altında büyüyebileceği üst sınır |
Ortam değişkeni tanımlanmazsa Gateway, pod'un gördüğü CPU core sayısına göre yukarıdaki varsayılanları kullanır.
CPU'ya Göre Önerilen Thread Değerleri
| CPU Core | tuneWorkerThreads | tuneWorkerMaxThreads |
|---|---|---|
| 1 | 512 | 1024 |
| 2 | 1024 | 2048 |
| 4 | 2048 | 4096 |
| 8 | 4096 | 8192 |
Genel kural: tuneWorkerThreads ≈ CPU × 512, tuneWorkerMaxThreads ≈ CPU × 1024. Bu değerler Undertow'un (Gateway'in kullandığı HTTP sunucusu) thread yönetim modeline dayanır.
Virtual Threads
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneRoutingVirtualThreadsEnabled | true | Backend yönlendirme çağrılarının virtual thread'lerde çalışmasını sağlar. false yapıldığında yönlendirme çağrıları isteği karşılayan worker thread üzerinde çalışır. Async executor çekirdeği o zaman tuneAsyncExecutorCorePoolSize olur. Üst sınır ve kuyruk yine uygulanmaz. |
tuneLoggingVirtualThreadsEnabled | true | Connector'lara (Elasticsearch bulk, webhook vb.) yapılan log yazımlarının virtual thread'lerde çalışmasını sağlar. |
IO Threads
IO thread'ler, network I/O işlemlerini (socket okuma/yazma) yöneten düşük seviyeli thread'lerdir.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneIoThreads | CPU core sayısı | IO Thread sayısı |
IO thread sayısı genellikle CPU core sayısına eşit tutulur. Artırmak çoğu senaryoda fayda sağlamaz; bağlam değiştirme (context switching) maliyetine yol açabilir.
Async Executor Thread Pool
RestApi politikası, Script politikası, loglama ve trafik aynalama bu havuzu kullanır. Havuz zamanlanmış görev kuyruğu kullanır. Üst sınır yazılsa da çekirdeğin üstüne çıkmaz. Kuyruk kapasitesi uygulanmaz.
Virtual thread açık
Varsayılan budur (tuneRoutingVirtualThreadsEnabled=true). Çekirdek 64'tür. Üst sınır 256 yazılır ve uygulanmaz. tuneAsyncExecutorCorePoolSize, tuneAsyncExecutorMaxPoolSize ve tuneAsyncExecutorQueueCapacity yok sayılır.
Virtual thread kapalı
tuneRoutingVirtualThreadsEnabled=false iken çekirdek tuneAsyncExecutorCorePoolSize olur. Bu değişken verilmezse çekirdek tuneWorkerThreads ile aynıdır. tuneAsyncExecutorMaxPoolSize ve tuneAsyncExecutorQueueCapacity yine uygulanmaz.
Connection Pool Tuning
Routing Connection Pool
Backend servislere yapılan HTTP bağlantılarını yöneten pool'dur. Yüksek eşzamanlı istek hacminde bu değerler kritiktir.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneRoutingConnectionPoolMaxConnectionPerHost | 1024 | Tek bir backend host'a açılabilecek maksimum bağlantı sayısı |
tuneRoutingConnectionPoolMaxConnectionTotal | 2048 | Tüm backend host'lara açılabilecek toplam maksimum bağlantı sayısı |
Ne zaman artırılmalı:
- 503 hataları veya connection timeout logları görüldüğünde
- Backend servisler yavaş yanıt verdiğinde ve bağlantılar tükendiğinde
- Eşzamanlı istek sayısı mevcut pool limitlerini aştığında
Cache Connection Pool
Cache servisleriyle yapılan bağlantıları yönetir.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneCacheConnectionPoolMaxConnectionTotal | 256 | Cache Connection Pool toplam maksimum bağlantı sayısı |
Elasticsearch Connection Pool
API trafik loglarının Elasticsearch'e yazılmasında kullanılan bağlantıları yönetir.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneElasticsearchConnectionPoolMaxConnectionPerHost | 256 | Elasticsearch host'u başına maksimum bağlantı sayısı |
API Call Connection Pool
Rest API Politikası ve benzeri politikalar tarafından yapılan harici API çağrılarını yönetir.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneApiCallConnectionPoolMaxConnectionPerHost | 256 | Host başına maksimum bağlantı sayısı |
tuneApiCallConnectionPoolMaxConnectionTotal | 4096 | Toplam maksimum bağlantı sayısı |
Timeout Tuning
| Parametre | Varsayılan | Açıklama |
|---|---|---|
tuneReadTimeout | 30000 ms (30 sn) | İstemciden veri okuma timeout'u. Client veri göndermezse bu süre sonunda bağlantı kapatılır |
tuneStreamingReadTimeout | 0 ms (sınırsız) | SSE/LLM streaming bağlantıları için istemci tarafı okuma timeout'u |
tuneNoRequestTimeout | 60000 ms (60 sn) | Bağlantı kurulduktan sonra istek gelmeme timeout'u |
Timeout Parametrelerinin Birbirleriyle İlişkisi
İstemci bağlantısı → tuneNoRequestTimeout (istek bekleme)
→ İstek geldi → tuneReadTimeout (veri okuma)
→ Streaming? → tuneStreamingReadTimeout
tuneNoRequestTimeout: Bağlantı açıldı ancak HTTP isteği gönderilmedi — boş bağlantıları temizlertuneReadTimeout: İstek işlenirken istemci veri göndermeyi durdurdu — takılı istekleri temizlertuneStreamingReadTimeout: SSE, Server-Sent Events, LLM streaming gibi uzun ömürlü bağlantılarda normaltuneReadTimeoutyetersiz kalır
SSE/LLM Streaming Senaryoları:
Streaming bağlantılarda istemci uzun süre veri göndermediği için normal tuneReadTimeout bağlantıyı erken kapatabilir. tuneStreamingReadTimeout ile streaming bağlantılarına özel timeout değeri atanır. Varsayılan 0 (sınırsız) değeri çoğu senaryo için uygundur; ancak kaynak sızıntısını önlemek için ortamınıza uygun bir üst limit belirleyebilirsiniz.
Benchmark Referans
Tier bazlı performans karşılaştırmaları ve detaylı benchmark sonuçları için Kapasite Planlama sayfasına bakın.
Benchmark sonuçları ideal koşullarda (hızlı backend, minimal network gecikmesi, sade politika zinciri) ölçülmüştür. Production ortamları için mutlaka kendi trafik desenlerinize göre yük testleri yapın.
İlgili Sayfalar
Otomatik bellek kademeleri, GC seçimi, jvmOverride ve heap yapılandırması
Donanım boyutlandırma, RAM hesaplama ve benchmark sonuçları
Gateway ortamlarının UI üzerinden yapılandırılması ve parametre referansı
Thread kullanımının zamana göre izlenmesi ve uyarı mekanizmaları