Türkiye sunucu mu yurt dışı mı: ping, TTFB ölçümü ve Türkiye lokasyonunun gerçekten gerektiği durumlar

Sunucu kiralamadan önce sorulan ilk sorulardan biri şu: Türkiye sunucu mu almalı, yoksa Frankfurt ya da Amsterdam gibi bir yurt dışı lokasyon mu? Bu sorunun cevabı kullanıcılarınızın nerede olduğuna ve sunucuda hangi işin çalıştığına bağlı. Bu rehber KOBİ sahipleri ve sistem yöneticileri için hazırlandı. Gecikmenin nereden geldiğini anlatıyor, iki lokasyonu kendi ağınızdan nasıl ölçeceğinizi gösteriyor ve web sitesi, uzak masaüstü ve ERP için karar ölçütleri veriyor.

Türkiye sunucu ile yurt dışı sunucu arasındaki gecikme farkı nereden gelir

Gecikmenin ana kaynağı fizik. Işık fiber içinde boşluktakinden yavaş ilerler: kabaca saniyede 200.000 km, yani her 100 km için tek yönde yaklaşık 0,5 ms. Gidiş dönüş (RTT) düşünüldüğünde her 100 km yaklaşık 1 ms ekler.

İstanbul ile Frankfurt arasındaki kuş uçuşu mesafe 1.800 km civarındadır. Bu, teorik olarak en az 18 ms civarında bir RTT anlamına gelir. Gerçekte kablolar düz gitmez, trafik birkaç yönlendiriciden ve bazen başka bir ülke üzerinden geçer. Bu yüzden ölçülen değer teorik sınırın üstünde çıkar. İstanbul'daki bir kullanıcının İstanbul'daki bir sunucuya gecikmesi ise genellikle tek haneli milisaniyelerde kalır, ama bu da kullanıcının internet sağlayıcısına ve sağlayıcının sunucunun bulunduğu ağla nasıl bağlandığına bağlıdır.

Gecikmeyi büyüten ikinci etken yönlendirmedir. Aynı şehirdeki iki ağ, birbirine yerel bir değişim noktasında değil de yurt dışında bağlanıyorsa paket önce dışarı çıkıp sonra geri döner. Bu nedenle "sunucu Türkiye'de" demek tek başına düşük gecikme garantisi değildir. Sağlayıcının hangi taşıyıcılarla ve hangi değişim noktalarında bağlı olduğu en az lokasyon kadar önemlidir.

Üçüncü etken, tek bir isteğin kaç kez gidip geldiğidir. HTTPS ile yeni bir bağlantı kurulurken önce TCP el sıkışması (1 RTT), sonra TLS 1.3 el sıkışması (1 RTT), sonra asıl istek (1 RTT) gerçekleşir. DNS sorgusu da cache'de değilse buna eklenir. Yani 40 ms'lik bir fark ilk baytın gelişinde 120 ms'ye dönüşebilir. Veritabanına doğrudan bağlanan masaüstü uygulamalarda bu çarpan çok daha büyüktür.

Kendi ölçümünüzü yapın: ping, mtr ve TTFB ile lokasyon karşılaştırma

Başka birinin ölçtüğü sayı sizin ofisinize, ISS'nize ve kullanıcılarınıza uymayabilir. Karar vermeden önce adayları kendi ağınızdan ölçün. Çoğu sağlayıcı test IP adresi, looking glass sayfası ya da kısa süreli deneme sunucusu sunar. Ölçümü sunucudan değil, kullanıcılarınızın oturduğu yerden yapın: ofis hattı, ev bağlantıları ve mobil hat ayrı ayrı.

1. Ping ile temel gecikme

Aşağıdaki komut Ubuntu 24.04, Debian 12 ve macOS'ta aynı çalışır. Sistemde değişiklik yapmaz, yalnız ölçüm alır. 192.0.2.10 yerine adayın test IP adresini yazın.

# 20 paket gönderir, sonunda özet satırı verir
ping -c 20 192.0.2.10

Çıktının son satırı şuna benzer:

rtt min/avg/max/mdev = 7.912/8.430/9.874/0.412 ms

Burada avg ortalama gecikme, mdev ise dalgalanmadır. Ortalaması düşük ama mdev değeri yüksek olan bir hat, uzak masaüstünde takılma olarak hissedilir. Windows'ta aynı ölçüm için ping -n 20 192.0.2.10 kullanabilirsiniz. Bazı sunucular ICMP'ye cevap vermez; bu durumda ping sonucunu kötü bağlantı sanmayın, aşağıdaki TTFB ölçümüne geçin.

2. mtr ile yol ve kayıp analizi

mtr, paketin geçtiği her yönlendiriciyi ve her adımdaki kaybı gösterir. Debian ve Ubuntu'da mtr-tiny paketiyle gelir. Kurulum ve ölçüm komutu Ubuntu 24.04 ve Debian 12 için hazırlandı; geri almak isterseniz sudo apt remove mtr-tiny yeterli.

# mtr kurulumu (zaten kuruluysa apt bir şey değiştirmez)
sudo apt update && sudo apt install -y mtr-tiny

# 100 paketlik rapor: -r rapor modu, -w geniş çıktı, -z AS numaraları, -c paket sayısı
mtr -rwz -c 100 192.0.2.10

Raporda bakmanız gerekenler:

• Son satırdaki Loss%: Hedefte kalıcı kayıp varsa sorun gerçektir. Aradaki bir yönlendiricide kayıp görünüp sonraki adımlarda sıfıra dönüyorsa, o cihaz yalnız ICMP'ye düşük öncelik veriyordur.
• AS numaraları: Trafik İstanbul'daki bir sunucuya giderken yurt dışı bir taşıyıcının AS'sinden geçiyorsa yönlendirme verimsizdir.
• Avg ile StDev: Son satırdaki standart sapma, ping'deki mdev ile aynı şeyi söyler.

3. curl ile TTFB ve bağlantı aşamaları

Web sitesi ya da API için en anlamlı ölçüm TTFB'dir (ilk baytın gelme süresi). Aşağıdaki betik her adres için 10 istek atar, ilk bayt süresine göre sıralayıp ortadaki ölçümü yazar. Ubuntu 24.04, Debian 12 ve macOS'taki bash ile kullanılmak üzere hazırlandı. Sistemde hiçbir ayarı değiştirmez; geri almak için dosyayı silmeniz yeterli. Adresleri aynı içeriği sunan iki aday sunucuya göre değiştirin.

#!/usr/bin/env bash
# lokasyon-olcum.sh: verilen her adres için TEKRAR kadar istek atar,
# TTFB'ye göre sıralayıp ortadaki (medyan) ölçümü yazar.
# Kullanım: bash lokasyon-olcum.sh https://example.com/ https://test.example.com/
set -euo pipefail

TEKRAR=10   # adres başına istek sayısı

if [ "$#" -eq 0 ]; then
  echo "Kullanım: $0 ADRES1 [ADRES2 ...]" >&2
  exit 1
fi

for URL in "$@"; do
  for i in $(seq 1 "$TEKRAR"); do
    # connect: TCP bağlantısı, appconnect: TLS bitişi, starttransfer: ilk bayt
    curl -o /dev/null -s -w '%{time_connect} %{time_appconnect} %{time_starttransfer}\n' "$URL"
  done | sort -k3 -n | awk -v url="$URL" '
    { c[NR]=$1; t[NR]=$2; s[NR]=$3 }
    END {
      m = int((NR + 1) / 2)
      printf "%s\n  tcp=%.3f s  tls=%.3f s  ttfb=%.3f s  (medyan, %d ölçüm)\n", url, c[m], t[m], s[m], NR
    }'
done

Beklenen çıktı şu biçimdedir:

https://example.com/
  tcp=0.009 s  tls=0.027 s  ttfb=0.142 s  (medyan, 10 ölçüm)

Sonucu şöyle okuyun: tcp değeri yaklaşık bir RTT'dir ve doğrudan lokasyonu yansıtır. tls ile tcp arasındaki fark ikinci RTT'dir. ttfb ile tls arasındaki fark ise sunucunun sayfayı üretme süresi artı bir RTT'dir. Eğer iki lokasyon arasında tcp farkı küçük ama ttfb farkı büyükse sorun mesafe değil, sunucunun kendisidir: PHP, veritabanı ya da cache ayarı. Lokasyon değiştirmek bunu düzeltmez.

Karşılaştırmayı adil yapmak için iki aday sunucuda aynı uygulamanın aynı sürümünü çalıştırın ve ölçümü günün farklı saatlerinde, özellikle mesai yoğunluğunda tekrarlayın.

Gecikme hangi işlerde önemli: web sitesi, RDP, Logo ve Mikro, API

Web sitesi ve e-ticaret

Kurumsal bir tanıtım sitesinde birkaç on milisaniyelik fark çoğu ziyaretçi için hissedilmez, çünkü toplam yükleme süresini görseller, betikler ve sunucu tarafı işleme belirler. E-ticarette ise sepet, ödeme adımı ve arama gibi cache'lenemeyen dinamik istekler her seferinde sunucuya gider. Ziyaretçilerin büyük bölümü Türkiye'deyse Türkiye sunucu bu isteklerde ölçülebilir fark yaratır.

Uzak masaüstü (RDP)

RDP gecikmeye toleranslı bir protokoldür; çalışır, ama yazarken ve fareyi sürüklerken her tuşun ekrana dönüşü RTT kadar gecikir. Gün boyu uzak masaüstünde çalışan bir ekip için düşük ve kararlı gecikme konforu doğrudan etkiler. Burada ortalama kadar dalgalanma da önemlidir; mtr'deki StDev değerine bakın. Ekip dışarıdan aynı uzak masaüstüne bağlanacaksa ölçümü ofisten ve birkaç ev bağlantısından ayrı ayrı alın.

Logo, Mikro ve diğer ERP yazılımları

Lokasyonun en kritik olduğu yer burasıdır, ama çoğu zaman yanlış nedenle. Logo, Mikro, Netsis gibi programların istemcisi SQL Server'a doğrudan bağlandığında tek bir ekran açılışı yüzlerce küçük sorgu üretebilir. Her sorgu bir RTT bekler. Bu yüzden istemci ofiste, SQL Server ise yurt dışındaysa program kullanılamayacak kadar yavaşlayabilir. Sunucuyu Türkiye'ye almak bu süreyi kısaltır ama mimari sorunu tamamen çözmez.

Doğru yaklaşım, ERP istemcisini SQL Server ile aynı veri merkezindeki bir RDS sunucusunda çalıştırmaktır. Böylece sorgular veri merkezi içinde, çok kısa sürelerde gidip gelir; kullanıcı ile sunucu arasında yalnız RDP ekran trafiği kalır. Bu durumda kullanıcıya yakın lokasyon RDP konforu için yine avantajlıdır. Hazır bir yapı arıyorsanız Logo sunucu sayfasında bu mimarinin Türkiye lokasyonundaki karşılığını görebilirsiniz.

API ve entegrasyonlar

API'nizi kim çağırıyor, ona bakın. Pazaryeri, kargo ya da e-fatura entegrasyonları Türkiye'deki servislerle konuşuyorsa Türkiye lokasyonu her çağrıda süre kazandırır. API'yi çağıran taraf Avrupa'daki bir SaaS ise yakın olan lokasyon Avrupa'dır. Bir iş akışında ardışık çok sayıda çağrı varsa küçük RTT farkları toplam süreyi belirgin biçimde uzatır.

Türkiye lokasyonunun SEO'ya etkisi: doğrudan değil, TTFB ve LCP üzerinden

Sunucunun ülkesi, Google için tek başına belirleyici bir sıralama sinyali değildir. Google'ın çok bölgeli siteler belgesi, hedef ülkeyi belirtmek için ülke kodlu alan adı (.com.tr gibi) ve hreflang gibi yöntemleri öne çıkarır. CDN kullanımı yaygın olduğu için sunucu IP'sinin konumu zayıf bir ipucudur.

Lokasyonun SEO'ya etkisi dolaylıdır: kullanıcı deneyimi ölçütleri üzerinden. Google Search Central'ın Core Web Vitals belgesi, LCP için 2,5 saniye ve altını iyi kabul eder. TTFB bir Core Web Vitals ölçütü değildir, ama LCP'nin ilk parçasıdır: ilk bayt gelmeden sayfanın hiçbir öğesi çizilemez. Türk ziyaretçilere uzak bir sunucu, her yeni bağlantıda birkaç RTT kaybettirir ve bu kayıp TTFB üzerinden LCP'ye yansır. Ancak yavaş bir veritabanı sorgusu ya da cache'siz bir WordPress, lokasyon farkından çok daha fazla süre kaybettirir. Önce yukarıdaki ölçümle sorunun kaynağını ayırın.

KVKK açısından lokasyon: kısa özet

Gecikme bir performans sorusudur, KVKK ise hukuki bir sorudur ve sonucu daha bağlayıcıdır. Kişisel veriyi yurt dışındaki bir sunucuda tutmak KVKK 9. madde kapsamında yurt dışına aktarım sayılır. Bu durumda standart sözleşme ve Kurul'a bildirim gibi yükümlülükler gündeme gelir. Müşteri, personel ya da hasta verisi işleyen bir ERP veya CRM için Türkiye lokasyonu bu yükü baştan ortadan kaldırır. Ayrıntılar ve yurt dışı VPS'ten geçiş adımları için KVKK uyumlu sunucu rehberine bakın. Bu bölüm hukuki görüş değildir; kendi durumunuz için hukuk danışmanınıza danışın.

Ne zaman yurt dışı lokasyon ya da CDN daha mantıklı

Türkiye lokasyonu her durumda doğru seçim değildir. Dürüst bir karşılaştırma:

Yurt dışı lokasyonun öne çıktığı durumlar

• Ziyaretçilerinizin ya da müşterilerinizin çoğu Avrupa'daysa, Avrupa'daki bir sunucu onlara daha yakındır.
• Uygulamanız Avrupa'daki bulut servisleriyle (depolama, kimlik doğrulama, ödeme dışı SaaS API'leri) yoğun konuşuyorsa, sunucuyu onların yanına koymak toplam gecikmeyi azaltır.
• GPU gerektiren yapay zeka işleri ya da paylaşılmayan donanım istiyorsanız seçenekler farklıdır: sunucu.com.tr'de GPU sunucular Frankfurt'ta, fiziksel sunucular Almanya, Fransa, ABD ve Singapur'dadır; bu ürünlerde Türkiye lokasyonu yoktur. Toplu model eğitimi gibi gecikmeye duyarsız işlerde bu genellikle sorun değildir.
• Felaket kurtarma için yedeğin ana sunucudan farklı bir ülkede durması bilinçli bir tercih olabilir. Kişisel veri içeriyorsa KVKK açısından ayrıca değerlendirin.

Türkiye lokasyonunun öne çıktığı durumlar

• Kullanıcıların büyük bölümü Türkiye'de ve iş etkileşimli: ERP, uzak masaüstü, e-ticaret sepeti.
• Kişisel veri işleniyor ve yurt dışı aktarım yükümlülüklerinden kaçınmak istiyorsunuz.
• Türkiye'deki servislerle (e-fatura, kargo, pazaryeri) sık entegrasyon var.

CDN ne zaman yeterli? İçeriğin büyük kısmı statikse (görsel, CSS, JavaScript, cache'lenebilir sayfalar) CDN bu dosyaları kullanıcıya yakın uç noktadan sunar ve sunucu lokasyonunun etkisini azaltır. Ancak CDN'in Türkiye'deki uç noktası olup olmadığı sağlayıcıya göre değişir; bunu sağlayıcının belgesinden kontrol edin. Giriş yapılmış kullanıcı sayfaları, sepet ve yönetim paneli gibi dinamik istekler yine kaynak sunucuya gider. ERP ve RDP için CDN bir çözüm değildir.

Türkiye sunucu seçerken kontrol edilecekler

Lokasyon kararını verdikten sonra sağlayıcıyı şu sorularla değerlendirin:

1. Veri merkezi: Hangi tesiste? Enerji ve soğutma yedekliliği nasıl? Tesisin sertifikaları (ISO 27001 gibi) belgelenebiliyor mu?
2. Taşıyıcılar ve bağlantı: Birden fazla upstream taşıyıcı var mı? Yerel değişim noktalarına bağlı mı? Bunu mtr çıktısındaki AS numaralarıyla kendiniz de doğrulayabilirsiniz.
3. Yurt dışı çıkış: Sitenizin yurt dışından da ziyaretçisi varsa, onların ölçümünü de alın. Yurt dışından gelen trafik için Türkiye lokasyonu daha uzak kalacaktır.
4. DDoS koruması: Koruma var mı, hangi katmanda ve saldırı anında ne oluyor: trafik temizleniyor mu, IP geçici olarak mı kapatılıyor?
5. Test imkânı: Test IP'si, looking glass ya da kısa süreli deneme var mı? Yoksa ölçmeden karar vermek zorunda kalırsınız.
6. Yedek ve snapshot: Yedekler aynı sunucuda mı, ayrı bir depoda mı tutuluyor? Geri dönüş nasıl yapılıyor?
7. Ölçeklenme: Yük arttığında CPU, RAM ve disk büyütülebiliyor mu, bunun için yeniden kurulum gerekiyor mu?

Sık yapılan hatalar

• Ölçümü sunucudan yapmak: Sunucudan kendi ofisinize ping atmak tersine bir ölçümdür ve ofis güvenlik duvarı ICMP'yi engelliyorsa hiç sonuç vermez. Ölçümü kullanıcı tarafından yapın.
• Tek bir ping'e güvenmek: Tek seferlik değer anlamsızdır. En az 20 paket, farklı saatler ve farklı bağlantılar kullanın.
• Yavaşlığı lokasyona bağlamak: TTFB yüksek ama TCP süresi düşükse sorun uygulamadadır. Lokasyon değiştirmek boşa bir taşıma olur.
• ERP istemcisini WAN üzerinden SQL Server'a bağlamak: Sunucu Türkiye'de bile olsa bu mimari yavaştır. İstemciyi sunucunun yanında, RDS üzerinde çalıştırın.
• KVKK'yı sonradan düşünmek: Veriyi yurt dışında tutmaya başladıktan sonra yükümlülükleri karşılamak, baştan doğru lokasyonu seçmekten zordur.
• Yurt dışı ziyaretçiyi unutmak: İhracat yapan bir firmanın sitesi için yalnız Türkiye'den ölçüm almak eksik bir karar üretir.

Sık sorulan sorular

Türkiye sunucu ile Frankfurt arasında ping farkı ne kadar olur?

Sabit bir sayı vermek yanıltıcı olur, çünkü fark ISS'nize ve sağlayıcının bağlantılarına göre değişir. Fiziksel alt sınır olarak İstanbul ile Frankfurt arası en az 18 ms civarında RTT ekler; gerçek değer bunun üstündedir. Kendi bağlantınızdan ping ve mtr ile ölçün.

Türkiye lokasyonu Google sıralamasını yükseltir mi?

Doğrudan değil. Google hedef ülke için alan adı uzantısı ve hreflang gibi sinyallere daha çok bakar. Türkiye lokasyonu, Türk ziyaretçiler için TTFB'yi düşürerek LCP'yi iyileştirebilir. Etkisi bu kullanıcı deneyimi ölçütleri üzerinden olur.

Logo veya Mikro'yu yurt dışındaki bir sunucuda kullanabilir miyim?

Teknik olarak RDS üzerinden kullanılabilir, çünkü sorgular veri merkezi içinde kalır. Ancak RDP gecikmesi daha yüksek olur ve kişisel veri içerdiği için KVKK kapsamında yurt dışı aktarım yükümlülükleri doğar. Çoğu KOBİ için Türkiye lokasyonu daha sade bir seçimdir.

Sitemin hem Türkiye'den hem Avrupa'dan ziyaretçisi var. Ne yapmalıyım?

Ziyaretçi dağılımınıza bakın ve dinamik isteklerin çoğunun nereden geldiğini belirleyin. Kaynak sunucuyu ağırlıklı kitleye yakın koyup statik içeriği CDN ile dağıtmak yaygın ve dengeli bir yaklaşımdır.

Ölçüm için sunucu kiralamam gerekiyor mu?

Gerekmez. Sağlayıcıdan test IP adresi ya da looking glass isteyin. Mümkünse kısa süreli bir deneme sunucusunda kendi uygulamanızın kopyasını çalıştırıp TTFB betiğiyle karşılaştırın; en güvenilir sonucu bu verir.

Bu işi hazır yapmak isterseniz

Ölçümleriniz Türkiye lokasyonunu işaret ediyorsa, bulut sunucu seçeneğini İstanbul lokasyonunda açıp aynı TTFB betiğiyle mevcut sunucunuzla karşılaştırabilirsiniz. Avrupa'daki kullanıcılar için Strasbourg (Fransa) lokasyonu da aynı panelden seçilebilir.

Sonuç

Türkiye sunucu ile yurt dışı lokasyon arasındaki seçim bir tercih meselesi değil, bir ölçüm meselesidir. Kullanıcılarınızın bulunduğu yerden ping, mtr ve TTFB ölçün. TCP süresi ile sunucu işleme süresini birbirinden ayırın. Etkileşimli işlerde (ERP, RDP, e-ticaret), Türkiye'deki kullanıcılarda ve kişisel veri işlenen sistemlerde Türkiye lokasyonu genellikle doğru seçimdir. Avrupa ağırlıklı kitlede, GPU gerektiren işlerde ve statik içerikte yurt dışı lokasyon ya da CDN daha mantıklı olabilir.