İstanbul vs Ankara veri merkezi: Gerçek fark nasıl ölçülür?

Veri merkezinin bulunduğu şehir, tek başına “daha iyi hosting” anlamına gelmez; asıl fark, kullanıcıya olan network gecikmesi (latency), hat kalitesi, rota (routing) ve servis mimarisiyle ortaya çıkar. Bu yazıda İstanbul ve Ankara veri merkezi tercihinde gerçekten neyin değiştiğini; TTFB, yükleme hızı, gün içi dalgalanma ve yedekleme/SLA gibi başlıklarla nasıl kontrol edeceğinizi netleştireceğiz. Sonunda da hedef kitlenize göre hangi şehirde daha doğru karar verileceğini pratik bir kontrol listesiyle okuyacaksınız.

İstanbul mu Ankara mı? Kararı belirleyen 4 somut etken

İstanbul–Ankara kıyasında çoğu kişinin baktığı ilk şey ping’dir. Ancak web trafiğinde tek başına ping genellikle doğru tahmin vermez. Aşağıdaki 4 kalem, gerçek kullanıcı deneyimini daha iyi açıklar:

1) Türkiye içi rota ve gecikme (latency)

• İstanbul tarafında, Marmara ve Trakya kullanıcıları genellikle daha düşük gecikme yaşar.
• Ankara tarafında ise Orta Anadolu kullanıcıları daha avantajlı olabilir.

Fakat farkı belirleyen sadece şehir değil; sağlayıcının internete çıkış noktası, bant sağlayıcı (transit) ve operatörler arası eşleşmeler (peering) olur.

2) TTFB (First Byte) ve önbellekleme davranışı

TTFB, “İstek geldi, ilk yanıt ne zaman döndü?” sorusunun cevabıdır. Statik içerik (CSS, JS, görseller) CDN/edge ile geliyorsa veri merkezi konumu etkisi azalır. Dinamik içerik (PHP, uygulama sorguları) için gecikme daha görünür hale gelir.

3) Sunucunun mimarisi: disk, CPU ve ağın gerçek kapasitesi

Veri merkezi şehri, CPU veya disk performansını doğrudan belirlemez. Aynı donanım sınıfında bile farklı SSD/NVMe profilleri, farklı I/O limitleri ve farklı sanallaştırma politikaları oluşabilir. Bu yüzden şehir kıyasını bant genişliği ve depolama performansı testleriyle birlikte yapmak gerekir.

4) SLA, yedekleme ve operasyonel süreklilik

Lokasyon, yedekleme stratejisini dolaylı etkileyebilir. Örneğin: - Otomatik yedeklemeler (backup) aynı lokasyonda mı tutuluyor, yoksa ikinci bölgeye mi gönderiliyor? - Donanım arızalarında “hot-swap” gibi prosedürler ne kadar hızlı işletiliyor?

Bu noktada “İstanbul daha iyi” gibi genellemeler yerine, sağlayıcının yedek (backup) politikası ve hizmet sürekliliği yaklaşımı esas alınmalıdır.

Testi doğru kur: ping yetmez, TTFB esas alın

İstanbul–Ankara kıyasını sağlıklı yapmak için şu sıralamayı izleyin.

Hedefinizi tanımlayın

• Kullanıcı kitleniz ağırlıkla İstanbul’da mı, Ankara/İç Anadolu’da mı?
• Web siteniz ağırlıkla dinamik mi (WordPress, uygulama) yoksa statik mi?

Ölçüm aracını doğru seçin

En pratik yöntemler: - Gerçek tarayıcı ile farklı şehirlerden test (mümkünse farklı operatörlerden) - Uptime/performans ölçümü (TTFB ve yüklenme süreleri) - Uzak sunucudan basit HTTP testleri

İpucu: Ping, genellikle sadece ICMP gecikmesini ölçer. Web isteklerinde TLS kurulum süresi, DNS, TCP/TLS handshake ve sunucu yanıtı birlikte rol oynar. Bu yüzden testte HTTP/HTTPS üzerinden TTFB’e bakmak gerekir.

Aynı senaryoyu iki lokasyonda da çalıştırın

Şu değişkenleri sabitleyin: - Aynı içerik (aynı WordPress sürümü, aynı eklentiler) - Aynı önbellek ayarları - Aynı dosya boyutları - Aynı trafik modeli (ör. her denemede 10 istek)

Gerçekçi beklenti: şehir farkı ne kadar hissedilir?

Genel olarak şu kural işe yarar: - CDN yoksa + dinamik içerik baskınsa: Veri merkezi lokasyon farkı daha görünür olur. - CDN/edge varsa + statik içerik baskınsa: Şehir farkı azalır; TTFB daha kritik hale gelir.

Somut örnek yaklaşımı (ölçüm mantığı): - İki sunucu arasında ortalama TTFB farkı küçük olsa bile, gün içi dalgalanma (peak saatlerde gecikme artışı) kullanıcı deneyimini daha fazla etkileyebilir. - Aynı sağlayıcıda, aynı sınıf VDS/VPS üzerinde kıyas yapmadığınızda “şehir” farkını “donanım/overselling” farkıyla karıştırma riski yükselir.

Bu nedenle karar verirken sadece “daha yakın şehir” yerine şu soruları netleştirin: - Sağlayıcı hangi saatlerde ölçüm yapınca SLA/performans veriyor? - Yedekler kaç saat gecikmeyle geri alınabiliyor? - Sunucu üzerinde disk IOPS ve ağ egress limitleri nasıl uygulanıyor?

İstanbul vs Ankara: pratik senaryo karşılaştırması

Aşağıdaki tablo, karar verirken hangi senaryoda hangi lokasyonun daha mantıklı olacağını anlatır. Burada “mutlak üstünlük” iddiası yoktur; amaç karar sürecini hızlandırmaktır.

Kontrol listesi: “hangi şehirde sunucu daha doğru?”

Bu bölüm, karar verirken doğrudan kullanabileceğiniz net kontroller içerir.

1) Sağlayıcıdan lokasyon kanıtı isteyin

• Veri merkezi tam adı ve adresi
• IP bloklarının gerçekten o lokasyondan çıkıp çıkmadığı
• Aynı sağlayıcıda “Türkiye’de birden fazla lokasyon” seçeneği varsa, iki lokasyon için de aynı paket/CPU/disk sınıfı sunuluyor mu?

2) Aynı paketi kıyaslayın (CPU/RAM/disk/ağ limitleri)

Şehir kıyası, teknik parametre sabit olmadığında yanıltır. Şu maddeleri aynı yapın: - VDS/VPS CPU tipi ve tahsis modeli - RAM garanti seviyesi - NVMe/SSD türü ve IOPS - Egress/bant genişliği ve hız limitleri - Sanallaştırma ortamı (aynı teknoloji olduğundan emin olun)

3) TTFB ölçümü yapın (en az 10 istek)

• Aynı URL setini kullanın: anasayfa + bir kategori + bir ürün/makale
• Ölçümü gün içinde iki zaman diliminde tekrarlayın: ör. 11:00 ve 20:00
• Sonuçları ortalama + maksimum olarak kaydedin

Beklenti: 1-2 lokasyon arasında “ortalama” fark küçük bile olsa, maksimum gecikme değerleri kullanıcı şikayetlerini daha iyi açıklar.

4) TLS/HTTP2/HTTP3 etkisini göz ardı etmeyin

Siteniz HTTPS üzerinden çalışıyorsa TLS handshake süresi ve protokol seçimi (HTTP/2 gibi) performansı etkiler. Lokasyon farkı yanında bu başlıklar sabit değilse sonuca güvenmek zorlaşır.

5) Yedek (backup) ve geri dönüş süresini netleştirin

Şehir seçiminizden bağımsız ama karar kalitenizi belirleyen kısım budur: - Otomatik yedekleme sıklığı (ör. saatlik/günlük) - Yedek saklama süresi - Yedekten geri dönüş prosedürü - Yedeklerin lokasyon bağımlılığı (aynı veri merkezinde mi, ayrı bölgede mi?)

Eğer sağlayıcı yedekleri ikinci bir lokasyona taşımıyorsa, lokasyon tek başına “risk azaltma” sağlamaz; daha iyi olan, yedekleme mimarisinin süreklilik planıdır.

SEO ve kullanıcı deneyimi: Lokasyonun etkisi nasıl yorumlanmalı?

Google’ın sıralama etkisini doğrudan “İstanbul’da olunca yükselirsin” şeklinde okumak doğru değildir. Ancak şunlar dolaylı olarak etki yaratır: - Sayfa yüklenme hızları ve kullanıcı etkileşimi - TTFB’nin artmasıyla birlikte daha yüksek terk oranı - Core Web Vitals metrikleri (LCP/INP/CLS)

Somut yaklaşım: 1) Önce TTFB’yi düşüren unsurları kontrol edin (önbellek, veritabanı sorguları, disk I/O) 2) Sonra veri merkezi lokasyonunu test edin 3) CDN kullanıyorsanız lokasyon farkı daha az görünür olur

Başka bir deyişle: Lokasyon farkı “asıl problem” olmamalı; önce uygulama ve önbellek mimarisi çözülmelidir.

Hangi durumda İstanbul, hangi durumda Ankara daha net tercih olur?

Aşağıdaki karar kuralları net sonuç üretir:

• Kullanıcı kitleniz ağırlıkla İstanbul + site çoğunlukla dinamik: İstanbul lokasyonunu test edin; çoğu durumda TTFB/ilk yanıt süresi daha avantajlı olur.
• Kullanıcı kitleniz ağırlıkla Ankara + İç Anadolu: Ankara lokasyonunu test edin; aynı paketle kıyaslandığında gecikme eğilimi daha iyi olabilir.
• Kullanıcı dağılımı ülke geneli ve CDN yok: İki lokasyonda da ölçüm yapın. Ortalama değer kadar “peak saat maksimumu” kritik.
• CDN var ve statikler yüksek paya sahip: Veri merkezi seçimi tek başına belirleyici olmaz. Dinamik isteklerin TTFB’sine odaklanın.

Sonuç: En doğru aksiyon, iki lokasyonu aynı paketle ölçmek

İstanbul ve Ankara veri merkezi arasında “kesin olarak şunu seç” demek teknik olarak doğru değil. Doğru yöntem, aynı uygulamayı aynı yapılandırmayla iki lokasyonda test etmek; özellikle TTFB ve gün içi zirve davranışına bakmaktır. Aksiyon önerisi: Önce hedef kitlenizi belirleyin, sonra sağlayıcıdan net lokasyon ve paket eşitliğini teyit edin, en az 10 istekle aynı URL setinde TTFB ölçümü yapın. Sonuçlarınız dinamik içerikte açık bir fark gösteriyorsa o lokasyonu seçin; fark yoksa maliyet ve SLA/yedekleme koşullarını esas alın.