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

Latency (Gecikme) neden veri merkezi seçiminde belirleyicidir?

Latency, bir isteğin veri merkezine gidip yanıtın geri gelmesi için geçen süredir. Aynı bant genişliğinde bile farklı bölgeler arasında gecikme, sayfa yükleme, API yanıt süreleri ve uygulama akıcılığı üzerinde doğrudan etki yaratır. Bu yazıda veri merkezleri arasında latency ölçümünü uçtan uca nasıl kurgulayacağınızı; ping, traceroute, TCP/HTTP testleri ve uygulama metriklerini birlikte değerlendirerek nasıl karar çıkaracağınızı öğreneceksiniz.

Aşağıdaki plan, özellikle VDS/VPS/Dedicated gibi sunucularda taşıyacağınız iş yükü için “hangi lokasyon daha hızlı?” sorusuna net yanıt verir.

Ölçüm hedefinizi doğru tanımlayın (latency tek sayı değildir)

Latency ölçümü yapmadan önce hangi tür gecikmeyi aradığınızı netleştirin. “Ping düşük olsun” yaklaşımı çoğu projede tek başına yeterli olmaz.

Uygulamanız hangi gecikme tipinden etkilenir?

• ICMP latency (ping): Ağ yolunun genel durumunu gösterir; ancak uygulama katmanını birebir temsil etmez.
• TCP handshake süresi: HTTPS gibi bağlantılarda “bağlantı kurma” gecikmesini etkiler.
• TLS (SSL) kurulum gecikmesi: İlk isteklerde daha belirgindir (özellikle oturum yeniden kullanımı zayıfsa).
• HTTP request/response time: Gerçek kullanıcı deneyimini en yakından temsil eden metriklerdir.
• Jitter (gecikme dalgalanması): Ortalama latency kadar önemlidir; özellikle gerçek zamanlı uygulamalarda (oyun, ses, trading) sıçramalar kritik olur.

Net metrik seti: Her testte aynı şeyleri ölçün

Aşağıdaki metrikleri aynı test koşulunda toplayın: 1. Average ping (ms) 2. %95 gecikme (p95) ya da p99 (ms) (uygulama testinde) 3. TCP connect time (ms) 4. HTTP(S) TTFB (time to first byte) ve toplam yanıt süresi (ms) 5. Jitter (opsiyonel ama önerilir)

Bu set sayesinde sadece “düşük ping” değil, “hızlı yanıt” kararı alırsınız.

Test ortamını kontrol altına alın: karşılaştırmayı bozan 6 faktör

Veri merkezleri arasında latency ölçerken sonuçları geçersiz kılabilecek faktörler vardır. Ölçümden önce bunları standartlaştırın.

1) Aynı protokol ve aynı hedef

• Aynı IP/hostname
• Aynı port (ör. 443)
• Aynı istek tipi (HEAD/GET)

2) Aynı trafik koşulları

• Mümkünse testleri çalışma saatleri ve farklı yoğunluk dönemlerinde tekrarlayın.
• Bir veri merkezinde aynı anda ağır iş yükü varsa “o anlık” gecikme ölçersiniz.

3) Aynı lokasyonda test noktası

“Ben A bölgesinden B’yi ölçtüm, C bölgesinden ölçtüm” diyorsanız karşılaştırma bozulur. Tek bir ölçüm sunucusu kullanın ya da dönüşümlü ölçümde aynı koşulları sağlayın.

4) DNS ve CDN etkisi

• DNS çözüm süresi için ayrı ölçüm yapın.
• CDN kullanıyorsanız “origin” ile “edge” arasını karıştırmayın.

5) Sunucu kaynakları (CPU/RAM) ve kernel gecikmesi

Ölçüm yapılan sunucu çok yüklüyse sizin testinizin sonucu da sapar. CPU %100 olduğunda TCP/HTTP zamanları uzayabilir.

6) Paket kaybı (packet loss)

Ping düşük ama paket kaybı yüksekse uygulama tarafında retransmit nedeniyle gecikme artar. Bu yüzden loss oranını göz ardı etmeyin.

Araç seçimi: latency ölçümünde pratik kombinasyon

Tek bir araçla her şeyi görmek mümkün değildir. En sağlıklı yaklaşım; katman katman ölçüm yapan bir kombinasyon kullanmaktır.

Önerilen araçlar ve neyi temsil ettikleri

• ping: ICMP latency ve packet loss
• traceroute: Trafik hattını (hop) görme
• mtr: Ping/traceroute birleşimi; jitter ve loss trendi
• TCP test (connect): 3-way handshake gecikmesi
• HTTP(S) test (TTFB + toplam): Gerçek kullanıcı deneyimi

Komut örnekleri (kısa ve karşılaştırılabilir)

Aşağıdaki komutları her hedef veri merkezi için aynı şekilde çalıştırın.

1) Ping ve packet loss

ping -c 20 -i 0.2 hedef_ip

2) MTR (jitter + kayıp trendi)

mtr -rwz -c 100 hedef_ip

3) TCP connect kontrolü

timeout 5 bash -lc 'cat < /dev/null > /dev/tcp/hedef_ip/443 && echo OK'

4) HTTP(S) TTFB ve toplam

curl -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\\n" -o /dev/null -s https://hedef_hostname/

Not: curl çıktısını her iki veri merkezinde de aynı URL ve aynı hostname ile karşılaştırın. Hostname farklıysa DNS ve routing değişebilir.

Veri merkezlerini karşılaştırma yöntemi: adım adım plan

Bu bölümde “sonuçlara bakıp karar vermeyi” kolaylaştıran bir workflow var.

1) Ölçüm sunucusu seçimi

• Uygulamanızın kullanıcılarına en yakın olmayan bir lokasyondan ölçüm yapmak genellikle yanlış olur.
• Eğer amacınız “iki veri merkezi arasında uygulama gecikmesi” ise ölçümü uygulamaya en yakın noktadan yapın.
• Eğer amacınız “kullanıcılar X bölgelerinde yoğun; hangisi daha iyi?” ise ölçümleri kullanıcı bölgelerine göre de çoğaltın.

2) Test matrisini kurun

Örnek matris: - Kaynak: A lokasyonundaki VDS/VPS - Hedefler: B lokasyonu 1 (DC-1), B lokasyonu 2 (DC-2) - Protokoller: 443 üzerinden HTTPS - Tekrar: her test 20-50 deneme

Markdown tabloyla düşünürseniz daha net olur:

3) Katmanları ayrı ayrı raporlayın

Aynı anda her şeyi okumak yerine şu sırayla ilerleyin: 1. Ping loss/paket kaybı var mı? 2. TCP connect süresi neden uzun? (routing mi, bant genişliği mi, yoğunluk mu?) 3. TLS süresi farklı mı? (sertifika/handshake etkisi) 4. TTFB ve total gecikme farkı hangi aşamada oluşuyor?

4) Sonuçları yorumlama: “hangi gecikme ne anlama gelir?”

• Ping benzer, HTTP total farklı: Sorun sadece temel hat değil; uygulama katmanı, sunucu kaynakları veya HTTP işleme farkı vardır.
• TCP connect farkı yüksek: Routing, firewall/anti-DDoS katmanı, SYN backlog veya NAT/edge katmanları etkili olabilir.
• TLS süresi yüksek: İlk el sıkıntısı (handshake) veya oturum yeniden kullanımında fark olabilir.
• TTFB yüksek ama total yakın: Sunucu ilk byte’ı geç gönderiyor; uygulama veya veritabanı tarafı etkili olabilir.

Ölçüm sonuçları nasıl kullanılmalı? (hedef eşiği çıkarın)

Net karar için “tek bir ms değeri” yerine hedef eşiği belirleyin.

Örnek eşiğe dayalı karar şablonu

Aşağıdaki gibi bir kıyas yapın: - Hedef: p95 TTFB - Kabul: p95 TTFB farkı %15’ten fazla ise veri merkezi seçiminde öncelik değiştir - Alarm: packet loss %1’in üstü ise bu lokasyonda uygulama davranışı dalgalanır

Load balancer / reverse proxy varsa ölçüm nasıl değişir?

Bir load balancer (LB) ya da reverse proxy araya giriyorsa gerçek “uygulama sunucusu” gecikmesi ölçülemez. Bu durumda: - Mümkünse origin IP üzerinden test edin. - Kullanılan WAF/anti-DDoS katmanları varsa aynı güvenlik profiliyle test edin.

Sık yapılan hatalar (bu hatalar ölçümü bozar)

• Sadece ping ile karar vermek: HTTPS tarafında TTFB farklı çıkabilir.
• Aynı URL’yi kullanmamak: Cache davranışı (server-side cache, browser cache) gecikmeyi değiştirir.
• Curl testlerinde Keep-Alive farkını sabitlememek: Özellikle birçok istek arka arkaya atılıyorsa bağlantı yeniden kullanımı fark yaratır.
• Tek sefer ölçüm almak: Latency kısa dönem dalgalanır; 20-50 tekrar standarttır.

Veri merkezi seçimi için pratik senaryolar

API veya mikroservis (stateless) senaryosu

• En kritik metrik: p95 TTFB ve toplam yanıt
• Ölçüm: /health veya küçük yanıtlı endpoint + gerçek istek boyutunda bir endpoint
• Karar: TCP connect farkı belirginse LB/WAF routing etkisi araştırılır

Gerçek zamanlı uygulamalar (oyun, ses, trading) senaryosu

• En kritik metrik: jitter ve packet loss
• Ölçüm: mtr ile 100+ hop kaydı, jitter trendi
• Karar: Ortalama latency iyi ama jitter yüksekse kullanıcı deneyimi bozulur

Büyük dosya yükleme / download senaryosu

• Latency tek başına belirleyici değildir; throughput ve paket boyutu da etkiler.
• Buna rağmen “ilk byte” gecikmesi (TTFB) start süresini etkilediği için yine HTTPS TTFB ölçümü yapın.

Sonuç: Latency ölçümünü katman katman yapın ve hedef metrikle karar verin

Veri merkezleri arasında latency ölçmek, doğru araçları seçip ölçümü standartlaştırdığınızda net sonuç verir. Tek bir ping sonucuna bakmak yerine ping/mtr, ardından TCP connect ve son olarak HTTPS curl çıktılarındaki TTFB + toplam gecikme metrikleriyle kıyas yapın. En iyi aksiyon: Önce iki veri merkezi için aynı kaynak lokasyondan 30 tekrar test çalıştırın, p95 değerlerini tabloya alın ve packet loss ile TCP/TLS/TFFB ayrımını raporlayın. Bu verilerle lokasyon seçimini “tahmin” yerine sayısal eşiğe bağlayarak netleştirebilirsiniz.