Veri merkezleri arası latency ölçümü: Net yöntemler ve kontrol listesi

Veri merkezleri (datacenter) arasında latency (gecikme), özellikle gerçek zamanlı uygulamalar, API entegrasyonları, görüntülü aramalar ve dağıtık sistemlerde performansı doğrudan etkiler. Ancak birçok ekip yalnızca tek bir ping sonucuna bakarak yanlış sonuca gider. Bu rehberde; ölçüm araçlarını, test senaryolarını, veri noktalarını ve sonuç yorumunu sistematik şekilde öğreneceksiniz. Böylece hangi lokasyonun ve hangi sağlayıcının gerçekten daha düşük gecikme sunduğunu net biçimde karşılaştırabileceksiniz.

Neyi ölçtüğünüzü netleştirin: latency tek sayı değildir

Latency, tek bir değerden ibaret değildir; ölçüm metodu ve katman değişince sonuç da değişir.

• ICMP latency (ping): Ağ katmanı hakkında fikir verir. Engellenmiş ICMP paketleri yüzünden yanıltabilir.
• TCP latency / handshake süresi: Uygulama bağlantısı kurma anındaki gecikme hakkında daha gerçekçi sinyal verir.
• TLS kurulum gecikmesi: HTTPS kullanıyorsanız (çoğu senaryoda) DNS + TCP + TLS toplamı önem kazanır.
• Uygulama round-trip time (RTT): Gerçek kullanımda istek/yanıtın tamamlanma süresi (server işlem süresi dahil) ölçülmelidir.

Net yaklaşım: Aynı karşılaştırmada en az iki katmanı birlikte değerlendirin. Örneğin ICMP (ping) + TCP/TLS/HTTP ölçümleri.

İdeal senaryo örneği

• Karşılaştıracağınız iki lokasyon: DC-A ve DC-B
• Ölçüm lokasyonu: Sizden çıkış yapan VPN/hat (ör. İstanbul’daki bir makine)
• Hedef: Hem IP hem alan adı bazlı test
• Süre: En az 30-60 dakika, gün içinde dalgalanmayı yakalamak için

Ölçüm mimarisi: kaynak, hedef ve zaman

Doğru latency kıyaslamak için üç şeyi standartlaştırın.

Kaynak (client) konumu sabit olmalı

Bir lokasyondan diğerine göre farklı modem/hat/ISP değişirse sonuç “sağlayıcı”dan çok “hat”a bağlı olur. Net karşılaştırma için: - Test makinesi konumunu sabitleyin. - Testleri aynı saat diliminde (örn. 14:00-16:00) tekrar edin.

Hedef (server) sabit olmalı

Aynı DC içinde bile farklı sunucu profilleri fark yaratır. Şunları sabitleyin: - Aynı RAM/CPU sınıfı (özellikle uygulama ölçümünde) - Aynı işletim sistemi ve container ayarları (eğer kıyas container üzerinden yapılıyorsa) - Aynı servis tipi (ör. yalnızca web endpoint’i değil; DB veya cache çağrılarını da benzer süreçlerle test edin)

Zaman ve yük faktörü

Datacenter içi ve omurga trafiği gün içinde değişir. Net ölçüm için: - Mümkünse birden fazla zaman aralığında test yapın. - Hedef sunucuda aynı anda büyük yük (backup, batch job, log rotation) olmadığından emin olun.

Temel ölçümler: ping, traceroute ve TCP/TLS

Aşağıdaki yöntemler; “ağ gecikmesi” ile “bağlantı kurma gecikmesi” arasındaki farkı görmenizi sağlar.

1) Ping ile ICMP latency ölçümü

ICMP engelli ise sonuç alamayabilirsiniz; yine de bazı servisler ICMP ile hızlı fikir verir.

• Hedef: Sunucunun IP’si (ve mümkünse alan adı)
• Parametre: Paket boyutu varsayılan kalabilir; ama tek tip kullanın

Net yorum kuralı: - DC-B’nin ping değeri daha düşük görünüyor ama TCP/TLS ölçümü aynıysa, ICMP tek başına karar vermek için yeterli değildir. - ICMP kaybı yüksekse uygulama trafiğinde de paket kaybı yaşıyor olma ihtimali artar.

2) Traceroute: rotayı görünür yapın

Traceroute, gecikmenin nerede arttığını anlamanıza yardım eder. Her hop aynı şekilde davranmaz; geçiş noktasındaki RTT sıçramaları “nerede sürpriz var?” sorusunu cevaplar.

Net yorum kuralı: - İlk 3 hop benzer, 4-6 hopta ciddi artış varsa sorun çoğunlukla sağlayıcı omurgasından veya bölgesel yönlendirmeden kaynaklanır. - Rotanız sürekli değişiyorsa (yüksek varyans), jitter uygulamanız için asıl risk olabilir.

3) TCP bağlantı testi: uygulama gerçekliğine yakın ölçüm

Ping yerine TCP handshake gecikmesini görmek için şu yaklaşım işe yarar: - Hedef porta TCP bağlantı kurma süresini ölçün (örn. 443)

Örnek hedef portlar: - 80/443: Web için - 22: SSH için - 25/587: SMTP için - DB portu: 5432 (PostgreSQL) / 3306 (MySQL) / 27017 (MongoDB)

Net yorum kuralı: - Ping düşük ama TCP handshake yüksek: Genellikle hedef tarafında SYN backlog, güvenlik duvarı (firewall) veya yoğunluk vardır.

4) TLS/HTTPS ölçümü: “İsteği gerçekten alan” perspektifi

HTTPS kullanıyorsanız, DNS çözümü + TCP + TLS + HTTP işlemlerinin toplam gecikmesini görmelisiniz.

Net yöntem: - Aynı endpoint için birden fazla tekrar alın. - Sadece “ilk yanıt” (TTFB) değil, toplam yanıt süresini izleyin.

Uygulama seviyesinde latency: en kritik katman

Birçok ekip şu hatayı yapar: “latency düşükse her şey iyi olur” der. Oysa gerçek gecikme, uygulama katmanındaki kuyruklarda ve işlem sürelerinde maskelenebilir.

5) HTTP GET/POST ile ölçüm (uygulama RTT)

• Basit bir endpoint seçin: Örn. küçük JSON dönen bir health check veya lightweight sorgu.
• HTTP/1.1 ve HTTP/2/HTTP/3 farklı davranabileceği için test ettiğiniz protokolü belirtin.

Net ölçüm standardı: - Her testte en az 20-30 tekrar alın. - İstatistik olarak yalnızca ortalamaya değil, p95/p99 değerlerine bakın.

6) Gerçek iş yükü: paralel istek + bekleme

API için latency tek başına yetmez. Aynı zamanda concurrency altında kuyruk oluşur.

Net senaryo: - 1, 5, 20 eş zamanlı istekle test edin. - Her kademede p95 gecikme artıyor mu, artış lineer mi yoksa ani mi izleyin.

7) DNS etkisini ayırın

DNS çözümü ilk isteklerde “ağ gecikmesi” sanılabilir. Net yaklaşım: - Mümkünse aynı resolver ile test edin. - İlk istek ile sonraki istekleri ayrı kaydedin.

Sonuçları nasıl karşılaştırırsınız? (puan tablosu yaklaşımı)

Tek bir sonuçla karar vermek yerine, testleri “kanıt seti” gibi düşünün.

Aşağıdaki örnek format, lokasyonları hızlı kıyaslamayı kolaylaştırır.

Net karar kuralı: - p95/p99 daha düşükse ve yük altında kuyruk daha yavaş büyüyorsa, lokasyon sadece “ortalama” değil “gerçek kullanıcı deneyimi” kazanır.

Ölçümü etkileyen yaygın tuzaklar (net kontrol listesi)

Aşağıdaki noktalar doğru ölçümün önündeki en sık engellerdir.

• ICMP engeli: Ping çalışmayabilir veya “kısmen çalışır” gibi görünebilir.
• Aynı donanım/plan olmaması: Bir lokasyonda daha hızlı CPU veya daha iyi ağ sınıfı varsa, latency farkı “lokasyon” değil “plan” olabilir.
• Güvenlik duvarı farklılıkları: SYN rate limit, WAF kuralları veya firewall policy gecikmeye neden olabilir.
• Önbellek (cache) farkları: CDN veya reverse proxy varsa “server latency” yerine edge gecikmesi ölçmüş olabilirsiniz.
• Protokol farkı: HTTP/3 veya HTTP/2 etkinliği farklıysa ölçüm kıyaslanamaz olur.
• DNS TTL ve resolver: Aynı alan adı ama farklı resolver kullanımı ilk istek gecikmesini değiştirir.
• Zaman penceresi: Tek seferlik ölçüm kararsız sonuç verir; jitter (dalgalanma) göz ardı edilir.

Lokasyon seçimi için pratik strateji: 3 adımda net karar

Latencem düşük olsun ama aynı zamanda maliyet ve iş yükü uygun olsun. Bu yüzden tek testle değil, üç adımlı bir süreçle ilerleyin.

Adım 1: Ağ sinyalini çıkarın

• Ping (ICMP) + traceroute ile rotadaki kabaca farkı görün.
• Buradaki amaç “neden fark var?” sorusuna ön bilgi toplamak.

Adım 2: Bağlantı kurma performansını doğrulayın

• TCP 443 (ve gerekli diğer portlar) handshake ölçün.
• TLS/HTTPS toplam gecikmeyi p95/p99 ile kıyaslayın.

Adım 3: Gerçek iş yükü altında test edin

• API/website için seçtiğiniz endpoint’i aynı istek profiliyle çalıştırın.
• Eş zamanlılık ve süre boyunca p95/p99 takibini yapın.

Uygulama türüne göre hedef metrikleri ayarlayın

Farklı uygulamalar farklı metriklere duyarlıdır.

Gerçek zamanlı (chat, oyun, VoIP)

• p95/p99 latency daha kritiktir.
• Paket kaybı ve jitter daha belirleyicidir.

API (REST/GraphQL) ve entegrasyonlar

• DNS + TCP + TLS + uygulama işlemi toplamı önemlidir.
• Yük altında p95 artışı, ölçeklenebilirliği gösterir.

Web siteleri (özellikle dinamik sayfalar)

• TTFB + toplam yüklenme zamanını birlikte değerlendirin.
• WAF/CDN kullanıyorsanız edge ve origin ölçümünü ayırın.

Sonuç: Net karar için tek sayı yerine kanıt seti kullanın

Veri merkezleri arasında latency ölçümünde en doğru yaklaşım, ping/traceroute ile başlayan; TCP/TLS ve ardından uygulama seviyesinde p95/p99 ile devam eden bir “kanıt seti” kurmaktır. Aksi halde ICMP düşük görünüp TCP veya gerçek endpoint ölçümlerinde kötü sürprizlerle karşılaşabilirsiniz.

Aksiyon önerisi: Karşılaştıracağınız iki lokasyon (DC-A/DC-B) için aynı kaynak makineden, aynı endpoint’le ve en az 20-30 tekrar yaparak p95/p99 değerlerini tabloya koyun. Sonuçlarda p95/p99 ve yük altında davranış birlikte daha iyi olan lokasyon, sadece ortalama latency’ye bakmaktan daha net bir seçim sağlar.