Veri Merkezleri Arası Latency Ölçümü: Net Test Rehberi

Veri merkezleri (data center) arasında latency (gecikme) ölçümü yapmadan seçilen bağlantı, çoğu zaman “fiyat iyi” gibi görünse bile uygulama performansını düşürür. Özellikle API çağrıları, veritabanı replikasyonu (replication) ve gerçek zamanlı servislerde gecikme; TTFB, işlem süresi ve hata oranlarını doğrudan etkiler. Bu rehberde veri merkezleri arasında latency’yi nasıl ölçeceğinizi, hangi metriklere bakmanız gerektiğini ve sonuçları nasıl net yorumlayacağınızı öğreneceksiniz.

1) Latency hangi gecikmeleri ölçer? (ICMP her şeyi anlatmaz)

Latency tek bir sayıyla açıklanmaz. Aynı hatta “ping 8 ms” görürken uygulama yine de yavaşlayabilir. Bunun nedeni; ölçtüğünüz yolun (path) ve protokolün farklı olmasıdır.

Hangi metrikler gerçekçi olur?

Aşağıdaki ölçümler farklı gecikme katmanlarını yakalar: - ICMP ping: Yolun (routing) genel durumu için hızlı sinyal verir. Ancak uygulama trafiğini birebir temsil etmez. - TCP handshake süresi: Port açma ve bağlantı kurma kısmı için ipucu verir. - TLS handshake süresi (HTTPS): Şifreleme katmanı devreye girerken ek gecikme olur. - TTFB / TTFB varyansı: En kritik uçtan uca kullanıcı deneyimidir (Time to First Byte).

Net kural: Aynı protokol, aynı yön

Veri merkezi A ile veri merkezi B arasını ölçüyorsunuz. Ölçümü: - Aynı protokolle (TCP/HTTP/HTTPS) yapın, - Aynı port ve aynı güvenlik katmanıyla (TLS varsa TLS) tamamlayın, - Trafiğin yönünü doğru ayarlayın (client->server).

2) Hangi ölçüm senaryosu sizin için doğru? (kullanım amacına göre)

Her kurum aynı şeyi ölçmez. Aşağıdaki senaryolar, hangi testi öne almanız gerektiğini belirler.

Senaryo A: Uzak veritabanı (DB) replikasyonu

Ölçmek istediğiniz: ağ gecikmesi + TCP kararlılığı.
Öncelik: TCP bazlı test + uygulama seviyesinde kısa istek/yanıt döngüsü.

Senaryo B: Uzak API çağrıları

Ölçmek istediğiniz: HTTPS/TLS katmanının ek maliyeti + uygulama TTFB.
Öncelik: HTTP/2 veya HTTP/3 test + düzenli tekrar (tekrarsız tek ölçüm yanlıştır).

Senaryo C: Gerçek zamanlı servis (chat, oyun, streaming ingest)

Ölçmek istediğiniz: jitter (gecikme dalgalanması) ve paket kaybı.
Öncelik: jitter/packet loss raporlayan araçlar ve uzun süreli ölçüm.

3) Ölçüm kurulum planı: Tek veri noktası değil, istatistik alın

Latency ölçümünde en sık hata, “10 kez ping attım, ortalaması iyiydi” demektir. Gerçekte jitter ve sıra dışı dalgalanmalar performansı bozar.

Test ölçüm parametreleri

Aşağıdaki hedefleri tutturun: - En az 3 test turu (her tur 1-5 dakika) - Tur aralarında en az 1 dakika ara - Her turda yeterli örnek: ping için ~300+ ICMP paketi iyi bir pratik eşiğidir - Gün içi farklı saatlerde test: aynı rota farklı yük altında farklı davranır

Ölçümün “yön” kısmı

Klasik kurulum: - Kaynak makine: veri merkezi/şehirden bağımsız bir konum veya hedefe yakın bir VDS - Hedef: ölçmek istediğiniz veri merkezi içindeki bir uç (ör. aynı sağlayıcının başka lokasyonundaki VDS)

Net yaklaşım: Mümkünse hem “A->B” hem “B->A” yönünü ayrı ayrı test edin. Simetrik olmayan rota sık yaşanır.

4) Araçlar: ICMP, TCP ve HTTP/HTTPS için net kombinasyon

Aşağıda farklı katmanlar için kullanılacak pratik yöntemleri bulacaksınız. Tek bir araçla “her şey” beklemeyin.

4.1 ICMP ile ön sinyal: ping

Amaç: rota kalitesinin hızlı sinyali. - Test: kısa aralık + ölçüm süresini uzat - Yorum: ortalama düşük ama jitter yüksekse, uygulama dalgalanabilir

Örnek (Linux): - ping -i 0.2 -c 300 hedef_ip

4.2 TCP handshake ölçümü: netcat (nc) veya benzeri

Amaç: port açma ve bağlantı kurma gecikmesi. - Test: hedef port (ör. 443) - Yorum: timeout artıyorsa bağlantı kurma katmanında problem var demektir

Örnek: - for i in {1..200}; do nc -vz -w 2 hedef_ip 443 2>&1 | grep -E "succeeded|open"; done

4.3 Uçtan uca HTTP/HTTPS: curl + tekrar

Amaç: DNS + TCP + TLS + ilk byte. - Test: gerçek endpoint (hostname) kullanın - Yorum: tek istek yerine tekrarlar ve varyans

Örnek: - for i in {1..100}; do curl -o /dev/null -s -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer}\n" https://hedef-domain.tld; done

Not: Buradaki alanlar şunları verir: - name lookup (DNS) - time_connect (TCP) - time_appconnect (TLS) - time_starttransfer (TTFB benzeri ilk byte)

4.4 Aktif ölçüm: trafiği benzeten araçlar (iperf3)

Amaç: bant/kapasite değil; özellikle jitter ve packet loss gözlemi için faydalı. - Yorum: yüksek packet loss varsa latency görünmez ama uygulama etkilenir

Öneri: “Latency odaklı” ölçüm için iperf3 tek başına yetmeyebilir; yine de ağ kalitesinin kanıtını güçlendirir.

5) Sonuçları net yorumlayın: “Düşük ms” yetmez

Aşağıdaki tablo, metriklere göre hızlı yorum sağlar.

Gözlenen sonuç	Muhtemel neden	Uygulama etkisi	Net aksiyon
Ortalama ping düşük, TTFB dalgalı	jitter, yoğunluk veya farklı rota	sayfa ilk yükleri tutarsız	aynı protokolle (HTTPS) tekrar ölç, jitter’i incele
TCP connect time yüksek	firewall/route/queue	API istekleri gecikir	hedef port ve güvenlik kuralını kontrol et
TLS handshake time yüksek	sertifika/CPU/elbette rota	HTTPS daha yavaş başlar	TLS offload/CPU spec’i ve lokasyonu kontrol et
Packet loss var	hat kalitesi / congestion	retransmit artar, süre uzar	daha iyi rota/peering talep et, saat bazlı test yap
DNS lookup yüksek	recursive DNS uzak/yoğun	ilk istekler yavaş	endpoint için doğru DNS, DNS TTL ve cache planı

6) Veri merkezi seçimi için pratik “test matrisi”

Bir sağlayıcıya karar vermeden önce veri merkezlerini aynı şablonda test edin. Böylece karşılaştırma net olur.

Test matrisi örneği (önerilen)

Aşağıdaki satırlar, ölçüm disiplinini sağlar: - Her sağlayıcı/plan için 1 VDS (aynı OS ve benzer CPU spec) - Her lokasyon çifti için 2 yön (A->B ve B->A) - Her yön için: - ICMP (300 ping) - HTTPS curl tekrarı (100 istek) - TCP 443 handshake testi (en az 200 örnek)

Karşılaştırma kriterleri (net)

Şunları sayısal olarak raporlayın: - TTFB (time_starttransfer) medyan - TTFB %95 (yüksek kuyruk) - TCP connect zamanının medyanı - Packet loss/timeout sayısı

Tek bir “ortalama” değere göre karar vermeyin. Özellikle %95 değer, gerçek kullanıcı deneyimini daha doğru yansıtır.

7) Latency ölçümünü doğru yapan güvenlik ve ağ ayarları

Yanlış güvenlik ayarı test sonucunu bozar. Özellikle data center içi/arası testlerde firewall ve NAT etkisi görülür.

Net kontrol listesi

Hedef portlar açık mı? (özellikle 443)
Security group / firewall kuralı test makinesinin IP’sini kabul ediyor mu?
ICMP engelse ping sonucu “ölü” çıkar; bu durumda HTTPS/TCP ölçümüyle devam edin.
Aynı OS sürümü ve benzer paket (ör. aynı MTU) kullanın.
Yükü bozacak eş zamanlı test sayısını abartmayın.

Uygulama tarafı ölçüm stratejisi

Sadece sentetik test değil, uygulama metriklerini de bağlayın: - API endpoint için ölçülen p95/p99 response time - Uygulama loglarında TLS/TCP time ayrımı (varsa) - Veritabanında sorgu süresi dağılımı

Sonuç: Kararınızı “ms ortalaması” yerine uçtan uca dağılımla verin

Veri merkezleri arasında latency ölçmek için tek doğru yaklaşım yok; doğru olan, hangi katmanı ölçtüğünüzü netleştirip aynı şablonda tekrar etmektir. ICMP ön sinyal verir, ancak HTTPS/TCP ve TTFB varyansı olmadan veri merkezi seçimi eksik kalır.

Aksiyon önerisi: Elinizde iki ya da daha fazla lokasyon alternatifi varsa, yukarıdaki test matrisini uygulayın ve kararınızı TTFB medyan + %95 ile verin. Timeout/packet loss ve TLS/TCP ayrımlarını da rapora ekleyin; böylece “iyi görünüyor” yerine ölçüme dayalı net bir seçim yaparsınız.