Sunucu Lokasyonu ve Gecikme (Latency) İlişkisi

Sunucu lokasyonu, sitenizin hızında donanımdan da yazılımdan da daha temel bir rol oynar; çünkü fizik yasalarını hiçbir optimizasyon değiştiremez. Almanya'daki bir sunucuda barınan siteniz, işlemcisi ne kadar güçlü olursa olsun, İstanbul'daki bir ziyaretçiye veriyi ışık hızından daha çabuk ulaştıramaz. Bu yüzden "sunucumu yükselttim ama site hâlâ yavaş" diyen çoğu kişinin asıl problemi işlem gücü değil, coğrafyadır.

Bu rehberde mesafenin gecikmeye nasıl dönüştüğünü, tek bir sayfa açılışında kaç kez gidip geldiğinizi, TLS el sıkışmasının bu maliyeti nasıl katladığını ve hedef kitlenize göre doğru lokasyonu nasıl seçeceğinizi anlatacağım. Ayrıca lokasyonun çözmediği problemleri, CDN'in nerede devreye girdiğini ve karar vermeden önce yapmanız gereken ölçümleri göstereceğim. Amaç, pazarlama iddialarına değil kendi ziyaretçi verinize dayanan bir seçim yapmanız.

Gecikme Nedir, Mesafe Nasıl Süreye Dönüşür#

Gecikme (latency), bir veri paketinin sizden hedefe gidip cevabın geri dönmesi için geçen süredir; genelde gidiş-dönüş süresi (RTT, round-trip time) olarak ölçülür ve milisaniye cinsinden ifade edilir. Bant genişliğiyle karıştırmayın: bant genişliği "saniyede ne kadar veri" sorusunun cevabıdır, gecikme ise "ilk baytın ne zaman geleceği" sorusunun. Bir gigabit hattınız olabilir ama sunucunuz uzaktaysa siteniz yine de geç açılır.

Işık boşlukta saniyede yaklaşık 300.000 km yol alır; fiber optik kablo içinde ise kırılma indisi sebebiyle bu hız kabaca üçte iki oranına, yani saniyede yaklaşık 200.000 km'ye düşer. Buradan çok kullanışlı bir kestirme çıkar:

Tek yön süresi  ≈ mesafe (km) / 200.000 km/s
RTT (gidiş-dönüş) ≈ 2 × tek yön süresi
Pratik kural: her 100 km için yaklaşık 1 ms RTT

Bu, teorik alt sınırdır ve gerçek dünyada asla elde edilmez. Kablolar kuş uçuşu gitmez, aradaki her yönlendirici paketi işlerken birkaç yüz mikrosaniye ekler, ve trafiğin yoğun olduğu bağlantı noktalarında kuyruk beklemesi olur. Pratikte ölçülen değerler teorik alt sınırın 1,5 ila 3 katı arasında çıkar. Türkiye merkezli bir ziyaretçi için tipik büyüklükler şöyledir:

Bu sayılar bağlantı tipine göre de kayar: mobil şebekede radyo katmanı tek başına 20–50 ms ekler, uydu bağlantısında yörünge yüksekliği yüzünden 500 ms'yi aşan değerler görülür. Yani ziyaretçinizin bağlantısı zaten bir taban gecikme taşır ve sunucu mesafesi bunun üstüne biner.

Tek Sayfa Açılışında Kaç Kez Gidip Geliyorsunuz#

Asıl mesele şudur: bir sayfa yüklenirken RTT bir kez değil, defalarca ödenir. Bu yüzden 40 ms'lik bir fark ekranda 40 ms olarak değil, çok daha büyük olarak görünür. Sıfırdan bir HTTPS isteğinin adımlarını sayalım:

1. DNS çözümlemesi — önbellekte yoksa en az bir RTT, zincir uzunsa daha fazla.
2. TCP el sıkışması — SYN, SYN-ACK, ACK: bir RTT.
3. TLS el sıkışması — TLS 1.3 ile bir RTT, TLS 1.2 ile iki RTT.
4. HTTP isteği ve ilk yanıt — bir RTT artı sunucunun üretim süresi.
5. Alt kaynaklar — aynı bağlantı üzerinden gelse bile her yeni ana bilgisayar yeni bir DNS + TCP + TLS zinciri demektir.

Yani ilk baytı almadan önce en iyi durumda dört RTT ödemişsinizdir. Bunu somutlaştıralım: sunucunuz Almanya'da ve RTT 50 ms ise, sunucu sayfayı üretmeye başlamadan önce yaklaşık 200 ms harcanmıştır. Aynı sunucu İstanbul'da ve RTT 12 ms olsaydı bu süre 48 ms olurdu. Yani sunucunuz sayfayı 100 ms'de üretse bile, kullanıcının gördüğü toplam fark 150 ms'yi aşar — ve bu, henüz hiçbir görsel yüklenmeden önceki farktır.

Bu zinciri kendi sitenizde adım adım ölçebilirsiniz:

# Her aşamanın süresini ayrı ayrı gör
curl -o /dev/null -s -w \
'dns:      %{time_namelookup}s
tcp:      %{time_connect}s
tls:      %{time_appconnect}s
ilk_bayt: %{time_starttransfer}s
toplam:   %{time_total}s
' https://firmaniz.com/

# Örnek çıktı (Almanya sunucusu, Türkiye'den ölçüm):
# dns:      0.032s
# tcp:      0.081s   -> TCP el sıkışması ~49 ms
# tls:      0.178s   -> TLS el sıkışması ~97 ms
# ilk_bayt: 0.402s   -> sunucu üretimi ~224 ms
# toplam:   0.418s

tcp ile dns arasındaki fark size ham RTT'yi verir; tls ile tcp arasındaki fark TLS el sıkışmasının maliyetidir ve genellikle RTT'nin bir ya da iki katıdır. Bu iki sayı, lokasyon kaynaklı kaybınızın doğrudan ölçüsüdür ve sunucunuzun ne kadar güçlü olduğuyla hiç ilgisi yoktur. Ölçüm yöntemlerinin tamamını ping ve traceroute ile gecikme ölçümü yazısında bulabilirsiniz.

Doğru Lokasyonu Seçmek: Kitleniz Nerede#

Karar kuralı basittir: sunucu, ziyaretçilerinizin çoğunluğuna en yakın yerde olmalıdır. "Çoğunluk" kelimesi burada anahtardır; kararı hissiyatla değil analitik verinizle verin. Ziyaretçilerinizin ülke dağılımına bakın ve ağırlık merkezini bulun.

Türkiye pazarına hizmet eden bir site için tercih sırası genellikle şöyledir:

Son satır teknik bir tercih değil bir yükümlülüktür ve bazı sektörlerde (sağlık, finans, kamu ile çalışan firmalar) kişisel verilerin yurt içinde tutulması gerekir. Bu durumda lokasyon tartışması zaten kapanmıştır.

Bir de gözden kaçan bir boyut var: yönetim ve destek. Sunucunuz yurt dışındaysa, ziyaretçi gecikmesinin yanı sıra sizin SSH oturumunuz, dosya yüklemeleriniz ve yönetim paneli kullanımınız da yavaşlar. 200 ms RTT ile bir terminal oturumunda her tuş vuruşunun ekrana yansıması gecikmeli hissedilir. Günlük operasyonun konforu, ölçülmeyen ama gerçek bir maliyettir.

Yerel bir lokasyonun ikinci avantajı eşleme (peering) kalitesidir. Türkiye'deki bir veri merkezi yerel internet değişim noktalarına doğrudan bağlıysa, Türk operatörlerdeki ziyaretçilere ulaşan yol kısadır. Yurt dışındaki bir sunucuda ise trafik, operatörünüzün yurt dışı çıkışına ve oradan hedef ağa taşınır; bu yol bazen coğrafi mesafeden çok daha uzun sürer. Bu yüzden "Almanya'da ama Türk operatörlere iyi eşlemesi olan" bir veri merkezi, "coğrafi olarak daha yakın ama kötü eşlenmiş" bir alternatiften daha hızlı olabilir. Ölçüm yapmadan haritaya bakarak karar vermeyin.

Lokasyonun Çözmediği Şeyler#

Lokasyonu doğru seçmek gecikmeyi düşürür ama sayfa hızının tamamını çözmez. Şu üç problem lokasyondan bağımsızdır:

Birincisi sunucu üretim süresi. Yukarıdaki curl çıktısında ilk_bayt ile tls arasındaki fark, sunucunun sayfayı üretmek için harcadığı süredir. Bu süre 800 ms ise, sunucuyu ziyaretçinin yanı başına taşısanız bile sayfa 800 ms'den önce gelmez. Bu kısım PHP, veritabanı ve önbellek işidir; veritabanı sorguları sayfa hızını nasıl etkiler ve sunucu tarafı önbellekleme katmanları yazıları bu tarafı ele alıyor.

İkincisi sayfa ağırlığı. 6 MB'lık bir ana sayfa, mesafe ne olursa olsun mobil bağlantıda geç yüklenir. Burada belirleyici olan bant genişliği ve kaynak sayısıdır; görselleri optimize etmek ve gereksiz betikleri kaldırmak lokasyon değişikliğinden daha büyük fark yaratır.

Üçüncüsü üçüncü parti kaynaklar. Sayfanızda dış bir yazı tipi, analiz betiği ya da sohbet aracı varsa, o kaynağın gecikmesi sizin sunucunuzun konumundan bağımsızdır. Ziyaretçi, sizin sunucunuza 10 ms'de ulaşırken bir dış betiği 300 ms'de indiriyorsa toplam süre yine uzar.

Bu yüzden lokasyon kararı bir "hızlandırma stratejisi" değil, bir taban belirleme kararıdır: elde edebileceğiniz en iyi süreyi belirler, ama o tabana ne kadar yaklaştığınızı yazılım tarafı belirler.

CDN Ne Zaman Lokasyon Sorununu Çözer#

CDN (içerik dağıtım ağı), statik dosyalarınızın kopyalarını dünyanın farklı noktalarındaki uç sunucularda tutar ve ziyaretçiye en yakın kopyadan sunar. Yani görselleriniz, CSS ve JavaScript dosyalarınız için mesafe problemini gerçekten çözer.

Ancak burada net bir sınır vardır ve çoğu kişi bunu kaçırır: CDN, önbelleğe alınamayan dinamik içeriği hızlandırmaz. Kullanıcıya özel bir panel sayfası, sepet, giriş yapılmış bir oturum ya da form gönderimi her seferinde asıl sunucuya (origin) gitmek zorundadır. CDN uç sunucusu bu isteği alır ve sizin sunucunuza iletir; yani mesafe hâlâ ödenir, üstüne bir de aradaki ek atlama gelir.

CDN'in gizli bir faydası da TLS el sıkışmasının uçta yapılmasıdır: ziyaretçi yakın uç sunucuyla el sıkışır, uç sunucu ile origin arasındaki bağlantı ise genellikle zaten açık tutulur. Bu, dinamik içerikte bile birkaç RTT kazandırabilir. Yine de asıl kural değişmez: kitleniz tek bir ülkedeyse, sunucuyu oraya koymak CDN'den daha basit ve daha etkilidir. CDN, kitle gerçekten dağınık olduğunda ya da statik ağırlığı yüksek olduğunda kazandırır. İkisi arasındaki tercihi CDN mi daha iyi hosting mi yazısında ayrıntılı karşılaştırdım; Cloudflare özelinde yapılandırma için Cloudflare DNS ve CDN yazısına bakabilirsiniz.

Karar Vermeden Önce Yapılacak Ölçümler#

Lokasyon değişikliği taşıma maliyeti olan bir karardır; öncesinde ölçüm yapın. İzlemeniz gereken sıra şudur:

1. Ziyaretçi coğrafyanızı çıkarın. Analitik aracınızdan son 90 günün ülke ve şehir dağılımını alın. Kararı oturum sayısına değil, dönüşüm getiren trafiğe göre verin.
2. Mevcut RTT'nizi ölçün. Farklı operatörlerden ve mobil şebekeden ping ve curl ölçümleri alın; tek bir noktadan yapılan ölçüm yanıltır.
3. Aday lokasyonu test edin. Sağlayıcıların test IP'lerine ya da test dosyalarına ping atarak aday veri merkezinin gerçek RTT'sini ölçün.
4. Sunucu üretim sürenizi ayırın. ilk_bayt eksi tls farkı büyükse, önce yazılım tarafını düzeltin; taşıma bunu iyileştirmez.
5. Yol haritasını kontrol edin. traceroute ile paketin hangi ülkelerden geçtiğine bakın; beklenmedik bir dolambaç varsa sorun mesafe değil yönlendirmedir.

# Aday lokasyona 20 paketlik ölçüm — ortalama ve kayıp oranı
ping -c 20 test.ornek.com

# Yolu ve her atlamadaki gecikmeyi gör
traceroute test.ornek.com

# Farklı saatlerde tekrarlayın: akşam yoğunluğunda değerler değişir

Ölçümü günün farklı saatlerinde tekrarlayın. Akşam saatlerinde yurt dışı çıkış hatları doluysa, gündüz 45 ms ölçtüğünüz bir yol akşam 120 ms'ye çıkabilir; asıl kullanıcı deneyimini belirleyen de o saatlerdir. Yük altındaki davranışı görmek için k6 ile yük testi yazısındaki senaryoları farklı lokasyonlardan çalıştırmak, tek seferlik ping ölçümünden çok daha bilgilendiricidir.

Sıkça Sorulan Sorular#

Sunucu lokasyonu SEO'yu etkiler mi#

Doğrudan bir sıralama faktörü olarak lokasyonun ağırlığı düşüktür; arama motorları hedef ülkeyi belirlemek için alan adı uzantısını, dil işaretlerini ve içeriğin kendisini kullanır. Ancak lokasyon dolaylı olarak etkiler: sayfa hızı ölçülen bir sinyaldir ve uzak bir sunucu ilk bayt süresini uzatır. Yani lokasyonun SEO etkisi, hız üzerinden gerçekleşir.

Türkiye'deki ziyaretçilerim için yurt dışı sunucu ne kadar yavaşlatır#

Almanya gibi yakın bir Avrupa lokasyonunda tipik RTT farkı 25–45 ms civarındadır. Ancak bir sayfa açılışında bu fark birkaç kez ödendiği için kullanıcının hissettiği gecikme genellikle 100–200 ms arasına çıkar. ABD gibi uzak lokasyonlarda fark yarım saniyeyi aşabilir. Kendi durumunuzu curl -w ile tcp ve tls sürelerine bakarak ölçebilirsiniz.

CDN kullanırsam sunucu lokasyonu önemsiz olur mu#

Hayır. CDN statik dosyalar ve önbelleğe alınabilen HTML için mesafeyi büyük ölçüde ortadan kaldırır, ama kullanıcıya özel dinamik sayfalar her zaman asıl sunucunuza gider. Panel, sepet, arama sonucu ve form gönderimi gibi işlemlerde origin mesafesi aynen ödenir. CDN, lokasyon seçimini tamamlayan bir katmandır; onun yerini almaz.

Ping süresi kaç ms olursa iyi sayılır#

Aynı ülkedeki bir sunucu için 5–25 ms iyi kabul edilir. Yakın Avrupa için 35–60 ms normaldir. 100 ms üzeri değerler kullanıcı tarafından fark edilmeye başlar, 200 ms üzeri ise etkileşimli kullanımda belirgin biçimde rahatsız edicidir. Mutlak sayıdan daha önemlisi tutarlılıktır: ortalama düşük ama sapma yüksekse (bazı paketler 20 ms, bazıları 300 ms) deneyim kötü hissedilir.

Sunucumu taşımadan gecikmeyi azaltabilir miyim#

Kısmen evet. TLS 1.3'e geçmek bir RTT kazandırır, HTTP/2 veya HTTP/3 kullanmak bağlantı sayısını azaltır, Keep-Alive süresini uzun tutmak tekrarlanan el sıkışmaları önler. Statik dosyalar için CDN eklemek büyük fark yaratır. DNS tarafında düşük TTL yerine makul bir TTL kullanmak ve hızlı bir DNS sağlayıcı seçmek de ilk isteği kısaltır. Ama ham mesafeyi ancak taşıma değiştirir.

Lokasyon seçerken veri merkezinin eşleme kalitesi neden önemli#

Coğrafi mesafe teorik alt sınırı belirler, ama paketin izlediği gerçek yol bunu kolayca ikiye katlayabilir. Yerel internet değişim noktalarına doğrudan bağlı bir veri merkezi, ziyaretçinin operatöründen kısa bir yolla ulaşılır. Kötü eşlenmiş bir veri merkezinde ise trafik başka ülkelere dolaşıp geri gelebilir. Bu yüzden karar öncesi traceroute ile gerçek yolu görmek, haritaya bakmaktan daha güvenilirdir.

Birden fazla ülkede ziyaretçim var, ne yapmalıyım#

Ağırlık merkezine göre tek bir asıl sunucu seçin ve önündeki katmanla mesafeyi yönetin: statik içerik için CDN, mümkünse anonim sayfalar için uçta tam sayfa önbellek. Gerçekten büyük hacimli ve coğrafi olarak dağınık bir trafiğiniz varsa, ayrı bölgelerde ayrı kurulumlar ve veri eşitleme gerekir; bu, karmaşıklığı ciddi biçimde artırdığı için ancak ölçüm bunu gerektirdiğinde tercih edilmelidir.

Kapanış#

Sunucu lokasyonu, sayfa hızınızın ulaşabileceği en iyi değeri belirleyen taban karardır; yazılım optimizasyonları sizi o tabana yaklaştırır ama altına indiremez. Aklınızda kalması gereken dört şey şudur: mesafeyi kabaca "her 100 km için 1 ms RTT" ile tahmin etmek, bu maliyetin tek bir sayfa açılışında birkaç kez ödendiğini unutmamak, kararı hissiyatla değil ziyaretçi coğrafyanız ve traceroute ölçümünüzle vermek, ve lokasyonun çözmediği sunucu üretim süresini ayrı bir iş olarak ele almak.

Türkiye'deki ziyaretçilerinize en yakın noktadan hizmet vermek isterseniz Clou.TR altyapısı buna uygun seçenekler sunar. Düşük gecikmeli barındırma için web hosting ve kurumsal hosting paketlerimizi, kendi yapılandırmanızı kurmak isterseniz VDS ve bulut sunucu çözümlerimizi inceleyebilirsiniz. Mevcut sitenizi daha yakın bir lokasyona almak isterseniz site taşıma hizmetimiz geçişi DNS ayarları dahil sizin yerinize yürütür.