Veri Merkezleri Arası Latency Ölçümü: Net Yöntem ve Karşılaştırma

Latency ölçümü, kullanıcı deneyimini doğrudan etkileyen “gizli” bir teknik kriterdir. CDN’in varlığı, uygulamanın önbellek mantığı ve hatta DNS çözüm süresi gibi birçok etken gecikmeyi değiştirir. Bu rehberde veri merkezleri (DC) arasında latency’yi doğru ölçmek için neyi nasıl ölçeceğinizi; hangi metrikleri baz alacağınızı ve sonuçları nasıl karşılaştıracağınızı net şekilde göreceksiniz.

Hedef: Tek bir “ping düşük çıktı” söylemi yerine; ölçümü tekrarlanabilir, raporu karar verdiren ve farklı sağlayıcı/konumları adil kıyaslayan bir çerçeve kurmak.

1) Latency hangi gecikmeleri kapsar? (ICMP her şeyi anlatmaz)

Önce terimleri netleştirmek gerekir. Kullanıcıyı etkileyen uçtan uca gecikme tek başına ICMP (ping) ile ölçülen şey değildir.

Uçtan uca gecikme katmanları

Aşağıdaki kalemler latency algısını etkiler: - DNS çözüm süresi (domain lookup) - TCP bağlantı kurulumu (SYN/SYN-ACK/ACK) ve varsa TLS el sıkışması - İlk byte’a kadar geçen süre (TTFB / Time to First Byte) - Sunucunun uygulama işleme süresi (CPU, veri tabanı, cache hit oranı) - Ağ katmanı: yönlendirme (routing), tıkanıklık (congestion), paket kaybı

ICMP ping, yalnızca ağ katmanındaki bir yolu taklit eder. Uygulama trafiğinde (HTTP/HTTPS) TLS ve servis katmanı devreye girdiği için, ping ile gerçek web gecikmesi her zaman aynı çıkmaz.

Karşılaştırmada kullanacağınız net metrikler

Bu rehberde aşağıdaki metrikleri esas alacağız: - One-way (tek yön) latency: Mümkünse en iyi; pratikte her zaman kolay değil. - RTT (round-trip time): Ping veya TCP testlerinde ölçülen gidiş-dönüş gecikme. - Packet loss (paket kaybı): Kaybın yükseldiği yerde RTT “dalgalanır”. - TTFB / TTFB: HTTP isteğine göre “ilk yanıt” zamanı. - p95/p99: Ortalama tek başına yanıltır. Kullanıcıların çoğu ortalamayı değil, kuyruk gecikmelerini yaşar.

Pratik kural: Veri merkezi seçimi yaparken p95 RTT ve p95 TTFB birlikte değerlendirilmelidir.

2) Ölçüm senaryosunu doğru kurun (adillik şart)

Sadece “server IP’sini pingle” yaklaşımı adil olmaz. Çünkü trafiğin yönü, protokolü ve önbellek durumunu kontrol etmeden veri merkezi kıyaslamak imkânsız hale gelir.

Aynı koşulları zorlayın

Aşağıdaki kontrolleri yapmadan kıyas kurmayın: - Aynı test noktası: Mümkünse tek bir istemci lokasyonu seçin (ör. İstanbul’daki bir VDS sunucusu). - Aynı protokol: HTTP/HTTPS mi, TCP portu mu, yoksa ICMP mi? - Aynı endpoint: Aynı uygulama (aynı test URL’si), aynı cache davranışı. - Aynı saat penceresi: Gündüz/gece trafik farkını yakalamak için en az 2-3 zaman dilimi test edin. - Aynı kullanıcı simülasyonu: Benzer paket boyutu ve benzer istek frekansı.

Ölçüm planı (önerilen minimum set)

1. ICMP ping ile paket kaybı ve RTT davranışı
2. TCP/TLS ile gerçek bağlantı gecikmesi
3. HTTP(S) ile TTFB ve kuyruk gecikmeleri (p95/p99)

3) Araç seçimi: Ne zaman ping, ne zaman HTTP ölçün?

Aşağıdaki araçları, amaçlarına göre eşleştirelim.

ICMP ping (yalnız ağ katmanı)

Ping kullanın: - Paket kaybını görmek için - Basit RTT kıyas yapmak için - Yönlendirme (routing) değişimlerini fark etmek için

Ping kullanmayın: - Web sayfası gecikmesini tahmin etmek için - TLS/uygulama etkisini dışarıda bırakacağı için tek metrik olarak

HTTP(S) ölçümü (kullanıcı deneyimi)

Tarayıcı gibi değil ama HTTP düzeyinde kullanıcı deneyimini yaklaşır: - TTFB / TTFB ile ilk yanıt gecikmesi - Cache hit/miss ile içerik katmanı

TCP/TLS ölçümü (bağlantı maliyeti)

İlk bağlantı maliyeti özellikle yeni bağlantılarda önemlidir: - TLS el sıkışması - TCP handshake gecikmesi

4) Net ölçüm: Linux’ta tekrarlanabilir komutlar

Aşağıdaki komutlar, ölçüm sürecini standardize eder. Her veri merkezi için en az 3 tur ve her turda yeterli örneklem (ör. 100+ paket veya 60+ saniye) hedefleyin.

ICMP ping ile RTT ve kayıp

Örnek:

ping -c 200 -i 0.02 -q <ip_adresi>

Hedef çıktıda şunları gözleyin: - RTT min/avg/max - packet loss

Tek bir “avg” değer yerine, jitter (dalgalanma) ve loss daha kritik olabilir.

TCP bağlantısı: port erişimi ve gecikme

Örnek (TCP port doğrulama):

timeout 5 bash -lc 'for i in {1..100}; do /dev/tcp/<ip_adresi>/<port> && echo ok; sleep 0.2; done'

Bu yöntem ham “bağlantı” davranışını görür. Daha rafine ölçüm için HTTP testleriyle devam edin.

HTTP(S) ile TTFB p95

Burada iki yaklaşım var: - Tarayıcı (karmaşıktır, cache/ek kaynaklar devreye girer) - HTTP istemcisi (daha deterministik)

Örnek olarak curl ile TTFB benzeri ölçüm yapılabilir (TTFB karşılığı, ilk byte zamanlaması):

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

Tek sefer yerine döngü kurun ve her ölçümü loglayın. Ardından p95’i hesaplayın.

p95/p99 nasıl çıkarılır?

Çıktıları bir dosyaya alıp değerleri bir istatistik aracında (veya küçük bir hesapla) p95/p99 yapın. NetKıyas’ta kıyas yapılırken tek tek ortalamalar değil, kuyruk gecikmeleri raporlanmalıdır.

5) Tekrar test ve raporlama: “Grafik” değil “karar” üretin

Ölçümün değeri, raporun bir seçim yaptırmasıyla gelir.

Veri toplama formatı

Her veri merkezi için aşağıdaki alanları kaydedin: - Lokasyon (ölçüm noktası) - Protokol (ICMP, TCP, HTTP/HTTPS) - Endpoint (IP veya domain, URL) - Örnek sayısı - p95 RTT (varsa p99) - packet loss - p95 TTFB - Not: cache durumu (ör. cache warm/cold)

Karşılaştırma tablosu (örnek şablon)

Aşağıdaki tablo formatını aynen kullanın:

Karar kriteri (net kural)

• Packet loss > %1: Bu seviyenin üstü ağ stabilitesini bozar. Latency iyi görünse bile kullanıcı tarafında gecikme anlık sıçrayabilir.
• TTFB p95, RTT p95’ten yüksekse: Problem yalnız ağ değil; uygulama, veritabanı veya cache ile ilgilidir.
• TTFB p95 yüksek ama loss düşükse: Uygulama/servis katmanı darboğazı olasılığı artar.
• TTFB p99 çok yüksekse: Kuyruk (tail latency) sorunu vardır. Bu durum özellikle anlık yoğunlukta “bazı kullanıcılar çok geç yükleniyor” şikayetlerini doğurur.

6) Yaygın hata senaryoları ve nasıl düzeltilir?

Aşağıdaki hatalar, veri merkezi kıyasını en çok bozan unsurlardır.

Hata 1: Sadece ping ile karar vermek

Ping düşük ama TTFB yüksek olabilir. TLS, uygulama işleme ve origin gecikmesi devreye girer. - Çözüm: ICMP + HTTP(S) + TTFB birlikte ölç.

Hata 2: Cache durumunu sabitlememek

Bir endpoint ilk erişimde cache cold olur, sonraki erişimlerde cache warm olur. - Çözüm: 2 aşamalı test yap. - Cold: Cache’i boşaltıp ilk tur - Warm: Kısa bir ısınma sonrası ikinci tur

Hata 3: Farklı URL’lerle ölçüm yapmak

/ home page yükleme farklı kaynaklar içerir. - Çözüm: Aynı test URL’sini (özellikle küçük, deterministik bir endpoint) kullan.

Hata 4: Ölçüm lokasyonunu değiştirmek

İstemci lokasyonu değişince routing tamamen farklılaşır. - Çözüm: Kıyas boyunca ölçüm noktası sabit kalsın.

Hata 5: Çok az örnekle çalışmak

Özellikle p95/p99 istatistikleri küçük örneklemle güvenilmez olur. - Çözüm: Her endpoint için yeterli örnek (ör. 60-180 sn veya 100+ istek).

7) “DC seçimi” kadar CDN ve yönlendirme neden kritik?

Veri merkezleri arası latency ölçümü yaparken şu gerçekle yüzleşmek gerekir: Kullanıcı trafiği her zaman doğrudan origin’e gitmeyebilir.

CDN varsa ölçtüğünüz şey CDN’işleyişi olabilir

• CDN POP (Points of Presence) kullanıcıya yakın olabilir
• Origin’e giden istekler ayrı bir latency ile ilerler

Bu nedenle iki ayrı ölçüm katmanı hedefleyin: 1. Kullanıcıya yakın noktadaki erişim (CDN TTFB) 2. Origin’den CDN POP’a giden durum (origin latency)

Aynı veri merkezi “aynı” değildir

Aynı ülke içinde bile farklı yönlendirme politikaları ve farklı AS/ISP yolları farklı RTT doğurur. - Çözüm: DNS ile gelen IP’leri sabitlemeden ölçmeyin (mümkünse AAAA/A kayıtları dahil netleştirin).

Sonuç: DC kıyasını p95 TTFB + packet loss ile yapın

Veri merkezleri arasında latency ölçümünü “ping ortalaması” ile değil; p95/p99 TTFB, RTT kuyrukları ve packet loss birlikte ele alarak yapın. En az iki aşamalı (cold/warm) HTTP(S) testi uygulayın ve her endpoint için tekrarlanabilir bir kayıt tutun.

Aksiyon önerisi: Hemen bugün kıyas yapmak için tek bir test lokasyonu seçin, her veri merkezi için aynı URL’de 2 tur HTTP(S) TTFB ölçümü alın, ardından tabloyu p95/p99 değerleriyle doldurun. Sonuçlar hazır olduğunda seçim; “en düşük ortalama” yerine kuyruk gecikmesi en iyi olan veri merkezine göre netleşecektir.