Ana içeriğe geç

Benchmark Sonuçları

uyarı

Bu sonuçlar politikasız (zero-policy) senaryoya aittir: yalnızca yönlendirme ve asenkron trafik loglama ölçülmüştür. Üretim ortamında aktif politikaların türüne ve sayısına göre değerler bu tabanın altında gerçekleşir. CPU'ya yoğun politikalar (XSLT, XSD doğrulama, şifreleme) throughput'u düşürürken; dış sistem çağrısı gerektiren politikalar (LDAP, OAuth2 introspeksiyon) yanıt süresini uzatır. Detaylar için Politika Performans Etkisi bölümüne bakınız.

Test Ortamı​

Benchmark, birbirinden izole dört farklı sunucu üzerinde gerçekleştirilmiştir. Her bileşen, ölçümlerin birbirini etkilememesi için ayrı makinelere konuşlandırılmıştır.

Load Generator
  • 6 vCPU · 12 GB RAM · 100 GB NVMe
  • wrk2 yük üretici aracı
  • CentOS, tek sunucu
Upstream (Backend)
  • 6 vCPU · 12 GB RAM · 100 GB NVMe
  • Go tabanlı yüksek kapasiteli HTTP sunucusu (~70K RPS)
  • Yük üretici ile ağ gecikmesi: ~0,5 ms
Elasticsearch
  • 8 vCPU · 24 GB RAM · 200 GB NVMe
  • Elasticsearch 8 — trafik log hedefi
  • Gateway sunucusundan fiziksel olarak ayrı
API Gateway (Worker)
  • 12 vCPU (Intel Broadwell @ 2.0 GHz) · 48 GB RAM · 250 GB NVMe
  • Kubernetes üzerinde çalışır
  • Yalnızca Worker pod'ları barındırır
bilgi

API Manager, MongoDB ve Kubernetes master ayrı bir sunucuda çalışmaktadır. Bu bileşenler gateway performansını doğrudan etkilemez; yük testi süresince yalnızca yapılandırma verisi sağlarlar.

Gateway Kaynak Konfigürasyonları (Tier'lar)​

Gateway, Kubernetes üzerinde dört farklı kaynak kısıtlamasıyla test edilmiştir. Her tier, gerçek üretim dağıtım senaryolarını temsil eder.

TierCPUBellekIO ThreadWorker ThreadVT Parallelism
W112 GB22561
W222 GB45122
W444 GB81.0244
W888 GB163.0728
not

JVM motoru tüm tier'larda G1GC'dir. Heap boyutu, Direct Memory ve GC bölge boyutu entrypoint tarafından tier'a göre otomatik belirlenir (W1/W2: Heap %60, W4/W8: Heap %65). Backend I/O ve trafik loglama Virtual Thread (VT), HTTP dispatch ise Platform Thread (PT) üzerinde çalışır.

Metodoloji​

Load Generator: wrk2​

Testler wrk2 ile gerçekleştirilmiştir. wrk2, koordinasyon sapmalarını (coordinated omission) önlemek amacıyla gerçek istek hızlarını izlemek üzere tasarlanmış yüksek hassasiyetli bir HTTP load generator'dır.

Temel parametre — R=999999 Overload Yöntemi:

wrk2 -t<thread> -c<connections> -d300s -R999999 --latency <url>

R=999999 hedef hızı, gateway'in kaldırabileceği maksimum RPS'nin çok üzerinde tutulmaktadır. Bu sayede ölçülen değer "ayarlanan oran" değil, sistemin ulaşabildiği gerçek maksimum throughput'tur.

Test Parametreleri​

ParametreDeğer
İstek tipleriGET · POST 1KB · POST 5KB
Süre300 saniye
TekrarHer bağlantı noktasında 3 kez
Raporlanan değer3 tekrarın ortalaması
Latency metrikleriP50 · P99
ES modlarıES Kapalı · ES Açık
PolitikaYok (zero-policy, saf yönlendirme)

Upstream Bottleneck Değil​

Upstream sunucusu, gateway'in maksimum throughput'unun yaklaşık 4–5 katını (~70.000 RPS) işleyebilmektedir. Ölçülen tüm sınırlar gateway kapasitesinden kaynaklanmaktadır; upstream bir darboğaz oluşturmamaktadır.

Yük üretici ile gateway arasındaki ağ gecikmesi ~0,5 ms olarak ölçülmüştür.

ES Modları​

  • ES Kapalı: Trafik logları Elasticsearch'e yazılmaz. Saf gateway overhead'ini ölçer.
  • ES Açık: Her istek için Elasticsearch'e asenkron trafik logu yazılır. Gerçek üretim senaryosunu simüle eder.

Sonuçlar​

1. Peak Throughput Özeti​

Her tier ve istek tipi için tüm bağlantı noktaları arasında gözlemlenen maksimum RPS değerleri.

ES Kapalı​

TierCPUGET (RPS)POST 1KB (RPS)POST 5KB (RPS)
W111.6381.4801.352
W223.8423.3223.097
W449.0788.0196.573
W8815.69212.9926.431

ES Açık​

TierCPUGET (RPS)POST 1KB (RPS)POST 5KB (RPS)
W111.4221.3421.148
W223.3852.4982.237
W447.4905.9805.147
W8814.25612.7046.543
Peak Throughput — ES Kapalı
ipucu

W8 tier'ında ES açık/kapalı farkı diğer tier'lara kıyasla çok küçüktür. 8 CPU'nun sağladığı asenkron işleme kapasitesi, Elasticsearch yazma gecikmesini büyük ölçüde absorbe etmektedir.

2. CPU Ölçekleme Verimliliği​

Birim CPU başına düşen RPS ve W1'e göre ölçekleme oranı (ES kapalı, GET).

TierCPUPeak RPSRPS/CPUÖlçekleme
W111.6381.6381.00×
W223.8421.9211.17×
W449.0782.2691.38×
W8815.6921.9611.20×
CPU Ölçekleme Verimliliği
bilgi

W1'den W8'e toplam artış 9,6×'tir. 8 CPU için teorik ideal olan 8×'in üzerine çıkılması (%120 verimlilik), gateway'in paylaşılan bağlantı havuzu ve sanal thread modeli sayesinde süper-lineer ölçeklenebildiğini göstermektedir.

3. ES Açık / Kapalı Karşılaştırması​

TierES KapalıES AçıkMaliyet
W11.6381.422%13,2
W23.8423.385%11,9
W49.0787.490%17,5
W815.69214.256%9,2
ES Kapalı vs ES Açık Karşılaştırması

4. Concurrency Eğrileri (Tier Bazlı)​

GET

BağlantıES-OFF RPSES-OFF P50ES-OFF P99ES-ON RPSES-ON P50ES-ON P99
1001.44756 ms3,15 s1.19829 ms720 ms
2501.44857 ms384 ms1.19831 ms165 ms
5001.63855 ms461 ms1.42265 ms304 ms

POST 1KB

BağlantıES-OFF RPSES-OFF P50ES-OFF P99ES-ON RPSES-ON P50ES-ON P99
1001.3382,48 s5,91 s1.09736 ms652 ms
2501.348103 ms1,57 s1.09945 ms658 ms
5001.48093 ms1,11 s1.34265 ms297 ms

POST 5KB

BağlantıES-OFF RPSES-OFF P50ES-OFF P99ES-ON RPSES-ON P50ES-ON P99
1001.19661 ms1,38 s89927 ms225 ms
2501.19970 ms796 ms89832 ms211 ms
5001.352107 ms540 ms1.14845 ms496 ms

5. JVM Diagnostics​

TierHeap KullanımıYoung GCOld GCThread (Peak)Blocked
W1135 / 1.189 MB (%11)14.923 kez / 343 s03510
W2201 / 1.230 MB (%16)7.245 kez / 156 s06090
W4724 / 2.664 MB (%27)10.570 kez / 213 s01.1290
W8933 / 5.328 MB (%18)14.308 kez / 192 s03.1890
not

Tüm tier ve modlarda Blocked thread sayısı 0 kalmıştır. Deadlock veya kaynak çakışması yaşanmamıştır.

Politika Performans Etkisi​

Benchmark sonuçları politika içermeyen saf yönlendirme senaryosunu ölçmektedir. Gerçek üretim senaryolarında her politika, kendi mekanizmasına bağlı olarak farklı bir maliyet kalemi ekler. Bu maliyetler iki temel kategoriye ayrılır: CPU yükü ve harici gecikme (latency).

CPU-Yoğun Politikalar — Throughput Düşürür​

Bu politikalar her istek için gateway üzerinde hesaplama yapar. CPU doğrudan tüketilir; tier büyütülerek veya yatay ölçeklenerek telafi edilebilir.

XML / XSD Şema Doğrulama

İstek veya yanıt gövdesi, yüklenen XSD şemasına göre her çağrıda parse edilip doğrulanır. Şema karmaşıklığı ve mesaj boyutu doğrusal biçimde CPU tüketimi artırır.

Örneğin 50KB XML gövdeli bir istekte karmaşık bir XSD şeması, ek politika olmaksızın bile throughput'u %30–60 oranında düşürebilir. Şema basit ve mesajlar küçükse etki sınırlı kalır.

XML Dönüştürme (XSLT)

XSLT, gateway üzerinde her istek için tam bir XML ayrıştırma ve şablon dönüştürme döngüsü çalıştırır. Karmaşık bir XSLT şablonu, CPU kullanımını tek başına ikiye katlamak için yeterlidir.

XSLT 1.0 ile 2.0 arasında işlem maliyeti önemli ölçüde farklılaşır. Büyük mesajlarda ya da sıkça tetiklenen endpoint'lerde W4 veya üzeri tier tercih edilmelidir.

JSON Şema Doğrulama

XSD doğrulamasının JSON eşdeğeridir. JSON body her istek için parse edilir ve tanımlı JSON Şema kurallarına göre gezilir. Şema derinliği (iç içe nesne sayısı) ile mesaj boyutu CPU tüketiminin başlıca belirleyicisidir.

Şifreleme / Şifre Çözme (WS-Security, JWE)

XML şifreleme, WS-Security gövde şifreleme veya JWE token şifresi çözme işlemleri, kriptografik işlemler içerdiğinden CPU kullanımını önemli ölçüde artırır. Özellikle asimetrik şifreleme (RSA) simetrik (AES) seçeneklere göre çok daha yüksek maliyetlidir.

Dijital İmza ve İmza Doğrulama (WS-Security, JOSE)

Her istek için imza hesaplanması ya da doğrulanması kriptografik işlem gerektirir. RSA-2048 veya RSA-4096 tabanlı imzalar, HMAC tabanlı alternatiflere kıyasla throughput üzerinde belirgin bir baskı oluşturur. Yüksek trafikli endpoint'lerde imza algoritması seçimi dikkatli yapılmalıdır.

İçerik Filtresi (Content Filtering)

Gövde içeriğini regex veya özelleştirilebilir kurallara göre tararken tüm mesaj her istek için değerlendirilir. Kural sayısı arttıkça ve mesaj büyüdükçe CPU maliyeti katlanarak artar.

Script Politikası (Groovy)

Groovy script'leri JVM üzerinde çalışır ancak başlangıç derleme maliyeti script cache ile azaltılmıştır. Bununla birlikte script içeriğinin karmaşıklığı doğrudan CPU kullanımını belirler. Döngü, parse ve hesaplama yoğun scriptler throughput'u ciddi ölçüde düşürebilir.

Harici Gecikme Ekleyen Politikalar — Yanıt Süresi Uzar​

Bu politikalar bir dış sisteme bağlanarak işlem yapar. Gateway CPU'su büyük ölçüde boşta beklerken, yanıt süresi harici sistemin gecikmesi kadar uzar. CPU büyütmek bu tür gecikmeyi azaltmaz; harici sistemin performansı ve ağ gecikmesi belirleyicidir.

LDAP Kimlik Doğrulama

Her istek için LDAP sunucusuna bağlanarak kullanıcı adı ve parola doğrulaması yapılır. LDAP sunucusuna gidiş-dönüş ağ gecikmesi (tipik olarak 1–10 ms) her isteğe eklenir. LDAP havuzu olmayan yapılandırmalarda bağlantı kurulum maliyeti de istek başına düşer.

LDAP sunucusu gateway ile aynı veri merkezindeyse etki nispeten sınırlı kalır; farklı veri merkezlerinde veya bulut ortamlarında gecikme onlarca milisaniyeye çıkabilir ve throughput orantısız biçimde düşer.

OAuth2 Token İntrospeksiyonu / OIDC

Token her istek için yetkilendirme sunucusuna (Authorization Server) gönderilerek doğrulatılır. Yanıt süresi tamamen AS'nin yanıt hızına bağlıdır. Token cache etkinleştirilmezse bu durum hem throughput hem latency üzerinde ciddi baskı oluşturur.

Token cache kullanıldığında cache miss oranına bağlı olarak maliyet önemli ölçüde azaltılabilir. Cache TTL'i iş gereksinimlerine göre dikkatli ayarlanmalıdır.

JWT (Uzak JWKS Doğrulaması)

İmza anahtarının uzak JWKS endpoint'inden alınması gerekiyorsa, her anahtar getirme işlemi ağ çağrısı anlamına gelir. JWKS cache etkinleştirildiğinde bu maliyet büyük ölçüde ortadan kalkar; cache süresi dolmadıkça ek gecikme oluşmaz.

SAML Kimlik Doğrulama

SAML assertion'larının IdP (Identity Provider) üzerinde doğrulanması gerekiyorsa harici bağlantı kaçınılmazdır. WS-Trust veya SOAP tabanlı IdP çağrıları hem ağ gecikmesi hem de işlem maliyeti ekler.

Backend Kimlik Doğrulama (Basic / API Key / Token)

Backend servisine iletilen kimlik doğrulama bilgilerinin her istekte yenilenmesi ya da doğrulanması gerekiyorsa (örneğin dinamik token alma) ek bir harici çağrı gerçekleşir. Statik kimlik bilgileri kullanıldığında bu maliyet oluşmaz.

API Çağrısı Politikası

Politika akışı içinde başka bir API'ye çağrı yapılması, o API'nin yanıt süresi kadar gecikme ekler. Seri birden fazla API çağrısı latency'yi katlar. Koşullu çalıştırma ve sonuç cache'leme ile bu maliyet minimize edilebilir.

Düşük Maliyetli Politikalar​

Aşağıdaki politikalar gateway üzerinde minimal CPU ve sıfır harici gecikme ekler. Yüksek trafikli ortamlarda bile performans üzerindeki etkileri genellikle ihmal edilebilir düzeydedir.

IP İzin / Yasaklama Listesi

Gelen IP adresi in-memory liste ile karşılaştırılır. Mikrosaniye mertebesinde tamamlanır.

Hız Sınırlama / Kota

Lokal sayaçlara veya paylaşılan önbelleğe karşı sayım yapılır. Önbellek entegrasyonu yoksa saf in-memory işlemdir.

Header Manipülasyonu

Belirli header'ların eklenmesi, silinmesi veya değiştirilmesi string işlemleridir; CPU maliyeti ihmal edilebilir.

Basic Kimlik Doğrulama (Yerel)

Kimlik bilgileri gateway'de tanımlıysa ve harici LDAP/dizin servisi yoksa, doğrulama tamamen in-memory gerçekleşir.

uyarı

Harici gecikme ekleyen politikalar throughput'u da düşürür; beklemedeki thread'ler yeni isteklere hizmet edemez. Dış sistem bağlantısına dayanan politikalarda W8 gibi yüksek thread kapasiteli tier'lar bu etkiyi önemli ölçüde azaltır.

Değerlendirme​

CPU Ölçekleme: Süper-Lineer Verimlilik

W1'den W8'e geçişte GET throughput'u 9,6× artmıştır. Teorik ideal olan 8×'in üzerine çıkılması (%120 verimlilik), paylaşılan bağlantı havuzu ve Java sanal thread modelinin birlikte sağladığı süper-lineer ölçeklenme kapasitesini göstermektedir.

Elasticsearch Loglama Maliyeti

ES loglama maliyeti tier büyüdükçe orantısız biçimde azalmaktadır. W8'de GET için yalnızca %9, POST 1KB için %2 throughput kaybı gözlemlenmektedir. 8 CPU'nun sağladığı asenkron işleme kapasitesi ES yazma gecikmesini büyük ölçüde absorbe etmektedir.

Politika Tasarımı için Mimari Öneri

CPU-yoğun politikaları (XSLT, şifreleme, şema doğrulama) koşullu çalıştırma ile yalnızca gerekli endpoint'lere sınırlayın. Harici gecikme ekleyen politikaları (LDAP, OAuth2 introspeksiyon) token/sonuç önbelleği ile destekleyin. Bu iki önlem birlikte uygulandığında politika maliyetinin büyük bölümü ortadan kalkar.

Kapasite Planlama Rehberi

Aşağıdaki değerler yalnızca yönlendirme + ES loglama içeren saf senaryoyu temsil eder. Politika yükü eklendiğinde gerçek kapasite bu değerlerin altında olacaktır.

Beklenen YükÖnerilen Başlangıç Tier
< 1.000 RPSW1
1.000–3.000 RPSW2
3.000–7.000 RPSW4
7.000–14.000 RPSW8
> 14.000 RPSW8 × N (yatay ölçek)

Cache Performansı​

Cache bileşeni, API yanıtlarını bellekte saklayarak tekrarlayan istekleri backend'e iletmeden doğrudan yanıtlar. Aşağıdaki sonuçlar, cache bileşeninin farklı kaynak konfigürasyonlarında GET (okuma) ve PUT (yazma) işlemlerindeki maksimum kapasitesini göstermektedir.

not

Cache bileşeni Hazelcast tabanlıdır ve ZGC çöp toplayıcı ile çalışır. JVM parametreleri her tier için entrypoint tarafından otomatik belirlenir. Test metodolojisi gateway benchmark ile aynıdır (R=999999 overload, wrk2).

Cache Kaynak Konfigürasyonları​

TierCPUBellekHazelcast Op ThreadsVT Parallelism
W112 GB21
W222 GB42
W444 GB84
W888 GB168

Maksimum Throughput​

TierCPUGET (RPS)PUT (RPS)
W112,1691,974
W225,0373,673
W447,8966,632
W8813,61913,069

CPU Ölçeklenme Verimi​

TierCPUGET RPSGET/CPUPUT RPSPUT/CPUÖlçeklenme (GET)
W112,1692,1691,9741,9741.00×
W225,0372,5193,6731,8371.16×
W447,8961,9746,6321,6580.91×
W8813,6191,70213,0691,6340.79×
bilgi

W1'den W8'e toplam artış GET için 6.3×, PUT için 6.6× olup CPU artışına (8×) yakın bir ölçeklenme göstermektedir. PUT işlemleri W8'de GET ile neredeyse eşit performansa ulaşarak yazma darboğazının yüksek CPU ile ortadan kalktığını göstermektedir.

Cache Kapasite Planlama​

Beklenen Cache YüküÖnerilen Başlangıç Tier
< 2.000 RPSW1
2.000–5.000 RPSW2
5.000–10.000 RPSW4
> 10.000 RPSW8
bilgi

Benchmark Sürümü: v1 · Test Tarihi: 27 Mart 2026 · Metodoloji: R=999999 overload, 300 s × 1 tekrar · Ortam: Kubernetes (isolated pod), Hazelcast 5.5 + Java 25 ZGC

Sonraki Adımlar​

Kapasite Planlama

Donanım gereksinimlerini ve boyutlandırma rehberini inceleyin

Deployment Topolojileri

Deployment topolojilerini ve yüksek erişilebilirlik seçeneklerini inceleyin

Politika Nedir?

Politika türleri ve uygulama mekanizması hakkında detaylı bilgi edinin

Mesaj İşleme ve Politika Uygulama

Gateway'in istek akışını ve politika sıralamasını öğrenin

bilgi

Benchmark Sürümü: v8 · Test Tarihi: 14 Mart 2026 · Metodoloji: R=999999 overload, 300 s × 3 tekrar · Ortam: Kubernetes (isolated pod), Undertow + Java 25 Virtual Threads

En son tarihinde güncellendi