New York VPS sunucusu seçerken nelere dikkat edilmeli

New York VPS size gerçekte ne sağlar

Bir New York VPS, Amerika Birleşik Devletleri doğu kıyısındaki iki büyük ara bağlantı pazarından birinde yer alır. Diğeri ise Ashburn, Virginia'dır. Satın aldığınız şey, Boston ile Washington arasındaki kullanıcılara kısa bir gidiş-dönüş süresi ve Kuzey Amerika'dan Avrupa'ya giden en kısa fiber yoludur. Kullanıcılarınız kıtaya eşit şekilde dağılmışsa, merkezi bir konum genellikle onlara daha iyi hizmet verir; bu iki durumu birbirinden ayırmak ise bir tahminden ziyade ölçüm gerektiren bir süreçtir.

Neden New York VPS barındırma hizmetlerinin çoğu New Jersey barındırma hizmetidir

Manhattan, taşıyıcı otellerine (carrier hotel) ev sahipliği yapar. 60 Hudson Street bunlardan en meşhurudur: 1930 yılında tamamlanmış, Tribeca'da bulunan bir Art Deco binadır. İçerisinde 300'den fazla taşıyıcı ve bulut sağlayıcısı ile DE-CIX New York ve NYIIX dahil olmak üzere bölgeye hizmet veren değişim noktaları bulunur. 32 Avenue of the Americas birkaç blok ötede aynı işlevi görür; Newark'taki 165 Halsey Street ise New Jersey tarafındaki karşılığıdır.

Bu binalar, ağların birbirleriyle buluştuğu noktalardır. Ancak büyük miktarda işlem gücü burada barındırılmaz; çünkü Manhattan'da elektrik ve zemin alanı oldukça pahalıdır ve genişletilmesi zordur. Büyük veri merkezleri Hudson Nehri'nin karşı kıyısında; Secaucus, Weehawken, Carteret, Piscataway ve Newark'ta yer alır. "New York" VPS hizmeti satan bir sağlayıcı, neredeyse her zaman Midtown'dan yaklaşık 40 km mesafedeki bu halka içerisinde bir kabin kastediyordur. Ekstra fiber maliyeti bir milisaniyenin çok altındadır, bu nedenle bir web iş yükü bunu asla fark etmeyecektir. Belirli bir ağa çapraz bağlantı (cross-connect) kurmanız gerekmedikçe hangi binada olduğunu sormanıza gerek yoktur.

Bu metropolün kapasitesini ne tetikledi

Dört temel etken var ve her biri diğerini güçlendiriyor.

• Transatlantik kabloları hemen yan tarafta karaya çıkıyor. New Jersey kıyısındaki Wall Township ve Manasquan, ülkedeki en yoğun kümelenme merkezleridir. AEC-2 olarak satılan Havfrue, Wall'dan Danimarka'daki Blaabjerg'e uzanır ve İrlanda ile Norveç'e kolları vardır. Seabras-1 aynı istasyondan Brezilya'ya giderken, TGN Atlantic Avrupa'ya geçer. Apollo, İngiltere'deki Bude ve Fransa'daki Lannion'dan gelerek Manasquan'da karaya ulaşır. Google'ın Grace Hopper kablosu Long Island'daki Bellport'ta karaya çıkar ve Eylül 2022'den beri Bude'ye trafik taşımaktadır.
• Borsalar Wall Street'ten ayrıldı. NYSE eşleştirme motoru Mahwah'ta, Nasdaq'ınki Carteret'te, Cboe'ninki ise Secaucus'ta çalışır. Yatırımcılar bu bölgelere "hisse senedi üçgeni" adını verir. Piyasa verisine mikrosaniye mertebesinde ihtiyaç duyan firmalar, bu merkezlerden birinin yanından alan kiralamak zorundadır; bu talep, geri kalanımızın bugün paylaştığı fiber altyapısının maliyetini karşılamıştır.
• Medya ve reklamcılık burada. Gerçek zamanlı teklif verme (real-time bidding) açık artırmaları, sayfa yüklenmesi tamamlanmadan yanıt dönmek zorundadır; bu nedenle reklam borsaları, satış yaptıkları ajans ağlarının yanına kurulmuştur.
• Ağlar, ağların zaten bulunduğu yere gider. Bir kez birkaç yüz taşıyıcı aynı binayı paylaştığında, bir sonraki taşıyıcı için başka bir yere inşaat yapmaktansa onlara katılmak daha ucuz transit ve daha iyi peering (eşleme) sağlar.

Bir VPS alıcısı için bunların hiçbiri prestij meselesi değildir. Bu durum, transitin rekabetçi, peering'in yoğun ve Avrupa'ya giden yolun kabloların başladığı noktadan itibaren kısa olması anlamına gelir.

Bir gidiş-dönüş süresinin gerçek maliyeti

Cam içindeki ışık, saniyede yaklaşık 200.000 km hızla hareket eder; bu da vakumdaki hızının yaklaşık üçte ikisidir. Bu, herhangi bir yönlendirici pakete dokunmadan önce, her 100 km fiber için 1 ms gidiş-dönüş süresi (round-trip time) demektir. Gerçek yollar harita üzerindeki mesafeden daha uzundur, çünkü fiber hatları düz çizgiler yerine geçiş haklarını ve deniz tabanı rotalarını takip eder.

Fatura tek bir gidiş-dönüşten ibaret değildir. Protokolünüzün ihtiyaç duyduğu gidiş-dönüş sayısıdır. Yeni bir HTTPS bağlantısı, TCP (transmission control protocol) el sıkışması için bir gidiş-dönüş, TLS (transport layer security) 1.3 el sıkışması için bir gidiş-dönüş ve isteği gönderip ilk baytları geri almak için bir gidiş-dönüş daha harcar. Tarayıcı herhangi bir HTML görmeden önce bu üç gidiş-dönüş demektir. TLS 1.2 ise dördüncüsünü ekler.

[
  {
    "label": "Same metro",
    "rtt_ms": 5,
    "https_first_byte_ms": 15,
    "six_call_chain_ms": 30
  },
  {
    "label": "New York to Dallas",
    "rtt_ms": 38,
    "https_first_byte_ms": 114,
    "six_call_chain_ms": 228
  },
  {
    "label": "New York to London",
    "rtt_ms": 78,
    "https_first_byte_ms": 234,
    "six_call_chain_ms": 468
  },
  {
    "label": "New York to Singapore",
    "rtt_ms": 230,
    "https_first_byte_ms": 690,
    "six_call_chain_ms": 1380
  }
]

Bu sütunlar ölçümden ziyade aritmetiktir: ilk bayt üç gidiş-dönüş sürer ve zincir sütunu, art arda altı bağımlı API çağrısını tetikleyen bir sayfayı temsil eder. Şehir içinde 5 ms sürede bağlantı kurulumu fark edilmez. Atlantik genelinde 78 ms sürede aynı sayfa, HTML'in ilk baytı için 234 ms bekler ve altı çağrılı zincir, hiçbir şey yapmadan sadece bekleyerek 468 ms harcar. New York'tan Singapur'a 230 ms sürede, bu zincirin maliyeti 1380 ms olur.

Bir sunucuyu taşımadan önce zincir sütununu inceleyin. Bağlantı yeniden kullanımı ve TLS oturum devam ettirme, sürekli ödediğiniz gidiş-dönüş maliyetlerini ortadan kaldırır. Altı bağımlı çağrıyı iki paralel çağrıya dönüştürmek, bir kıta yakınına taşınmaktan daha fazla zaman kazandırır. Sunucuyu, gidiş-dönüş süreleri indirgenemez olduğunda taşıyın: bir oturum açma işlemi veya istemcinizin toplu işleyemediği bir veritabanı yazma işlemi gibi.

New York metro bölgesindeki bir VPS'ten tipik gidiş-dönüş süreleri

[
  {
    "label": "Within the NY and NJ metro",
    "rtt_ms": 2
  },
  {
    "label": "Ashburn, Virginia",
    "rtt_ms": 8
  },
  {
    "label": "Toronto",
    "rtt_ms": 14
  },
  {
    "label": "Chicago",
    "rtt_ms": 22
  },
  {
    "label": "Dallas",
    "rtt_ms": 38
  },
  {
    "label": "Miami",
    "rtt_ms": 40
  },
  {
    "label": "Los Angeles",
    "rtt_ms": 70
  },
  {
    "label": "London",
    "rtt_ms": 78
  },
  {
    "label": "Frankfurt",
    "rtt_ms": 88
  },
  {
    "label": "Sao Paulo",
    "rtt_ms": 120
  }
]

Bu değerleri tek bir makineden alınan ölçümlerden ziyade, yayınlanmış tipik veriler olarak değerlendirin. Bunlar, iyi bağlantıya sahip ana bilgisayarlar için normal transit ağlarda yaygın olarak belirtilen aralıklardır; kendi ağ yolunuz bu değerlerin altında veya üstünde kalabilir. Ashburn yaklaşık 8 ms uzaklıktadır; bu mesafe, bir New York VPS'inin Virginia kümesindeki servisleri ciddi bir performans kaybı yaşamadan çağırmasına olanak tanır. Toronto yaklaşık 14 ms mesafededir. Londra 78 ms, Frankfurt ise 88 ms civarında yer alır. Bu nedenle, doğu yakasındaki bir sunucu Avrupalı kullanıcılara kabul edilebilir düzeyde hizmet verebilirken, batı yakasındaki bir sunucu bunu yapamaz.

Doğu Yakası yerleşimi neden doğru tercihtir

• Kullanıcılarınızın büyük çoğunluğu Boston ile Washington arasındaki koridorda yer alıyorsa. Bu hat, Amerika Birleşik Devletleri'ndeki internet trafiğinin büyük bir kısmını oluşturur ve bölgenin tamamı bu metropol merkezlerine birkaç milisaniye uzaklıktadır.
• Amerika Birleşik Devletleri'nin doğusuna ve Avrupa'ya tek bir makine üzerinden hizmet veriyorsanız. New York, transatlantik bağlantı noktası burada başladığı için en uygun maliyetli uzlaşma noktasıdır.
• Metropol içinde halihazırda bulunan bir kaynağa bağımlıysanız: Secaucus veya Ashburn'deki bir piyasa verisi akışı, reklam borsası veya iş ortağı API'si gibi.
• Kanada'da barındırma yapmadan oraya kısa bir erişim yolu istiyorsanız. Toronto, 14 ms civarındadır. Eğer Kanada'da veri barındırma zorunluluğu kesin bir gereksinimse, bu farklı bir karardır ve Kanada VPS barındırma seçerken gerçekten önemli olanlar konusu bu süreci detaylandırır.

Merkezi bir ABD lokasyonunun Doğu Yakası'nı geride bıraktığı durumlar

Ortalamayı değil, en kötü senaryoyu baz alarak tasarım yapın. Uzak kıyıdaki bir kullanıcı gecikmeyi fark eder. Bir sonraki eyaletteki kullanıcı ise fark etmez.

[
  {
    "label": "New York metro",
    "to_new_york_ms": 2,
    "to_los_angeles_ms": 70
  },
  {
    "label": "Dallas",
    "to_new_york_ms": 38,
    "to_los_angeles_ms": 35
  },
  {
    "label": "Chicago",
    "to_new_york_ms": 22,
    "to_los_angeles_ms": 50
  },
  {
    "label": "Los Angeles",
    "to_new_york_ms": 70,
    "to_los_angeles_ms": 2
  }
]

New York merkezli bir sunucu, Los Angeles'a 70 ms uzaklıktadır. Dallas merkezli bir sunucu ise New York'a 38 ms, Los Angeles'a ise 35 ms uzaklıktadır; dolayısıyla ülke genelindeki en kötü senaryo gecikmesi, New York'takinin yaklaşık yarısı kadardır. Trafik haritanız gerçekten ulusal ölçekteyse, bu daha güçlü bir konumdur ve Dallas'ta bir VPS bulundurmanın gerekçeleri bu pazarı detaylıca ele alır. Chicago, diğer mantıklı orta noktadır ancak konumu doğuya daha yakındır.

New York dışındaki lokasyonları işaret eden iki durum daha mevcuttur. Kullanıcılarınız Ontario veya Quebec'te yoğunlaşmışsa, Toronto VPS onları doğrudan karşılar; böylece New York üzerinden gelen 14 ms'lik ek sıçramadan kaçınılmış olur. Eğer trafiğinizin neredeyse tamamı kendi sunucularınız arasında gerçekleşiyorsa, sunucuları tek bir bölgede tutun ve coğrafyayı düşünmeyi bırakın; çünkü bölgeler arası bir sıçrama, kullanıcılara yakın olmaktan elde edeceğiniz her türlü kazancı etkisiz kılacaktır.

Ölçüm yapın, pazarlama haritalarına güvenmeyin

Kapsama haritası size bir binanın nerede olduğunu söyler. Paketlerin o binaya nasıl ulaştığını söylemez; bu yol mesafe ile değil, transit sözleşmeleri ve peering anlaşmaları ile belirlenir. Bu nedenle ölçümü kullanıcılarınızın bulunduğu yerden yapın. Ev internetine bağlı bir dizüstü bilgisayar, ağın iyi tarafında bulunan VPS'in kendisinden daha iyi bir sondadır.

sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3

İşe basit bir gidiş-dönüş süresi (round trip) ile başlayın ve dört yerine yirmi sonda gönderin. Hostname kısmını kendi sunucunuzla değiştirin.

ping -c 20 your-server.example.com

Son satır rtt min/avg/max/mdev değerini raporlar. Ortalama, oradaki en az yararlı sayıdır. mdev jitter değeridir; yüksek jitter, ortalama değer sağlıklı görünse bile sesli görüşmeleri ve etkileşimli oturumları bozar. Kablolu bir yolda, sıfırın üzerindeki her paket kaybı gürültü değil, bir arızadır.

Ardından zamanın nerede harcandığını bulun.

mtr -rwzbc 100 your-server.example.com

mtr her bir atlamaya (hop) 100 sonda gönderir ve her atlama için kayıp ve gecikme değerlerini yazdırır; -z ise AS (otonom sistem) numarasını ekleyerek her atlamanın hangi ağa ait olduğunu görmenizi sağlar. Orta bir atlamada raporlanan ve sonraki atlamalarda kaybolan kayıp gerçek değildir: o yönlendirici, kendi oluşturması gereken ICMP yanıtlarını hız sınırlamasına (rate-limiting) tabi tutuyordur ve bu durum trafiğinize zarar vermez. Bir atlamada başlayıp sonraki tüm atlamalarda devam eden kayıp ise gerçektir.

ICMP, bir web servisini değerlendirmek için de yanlış protokoldür çünkü birçok ağ buna düşük öncelik verir. Gerçekte sunduğunuz şeyi zamanlayın.

curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/

Her değer başlangıçtan itibaren kümülatif saniyelerdir, bu yüzden okumak için çıkarma işlemi yapmanız gerekir. time_connect eksi time_namelookup bir gidiş-dönüş süresidir. time_appconnect eksi time_connect TLS el sıkışmasıdır. time_starttransfer eksi time_appconnect bir gidiş-dönüş süresi daha ve uygulamanızın yanıt vermesi için geçen sürenin toplamıdır. Bu son çıkarma işlemi teşhistir. Eğer sonuç bir gidiş-dönüş süresine yakınsa, sınır ağdır ve daha yakın bir sunucu yardımcı olacaktır. Eğer sonuç gidiş-dönüş süresinin birkaç katıysa, uygulamanız yavaştır ve sunucuyu taşımak hiçbir şeyi değiştirmez.

for i in $(seq 1 20); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'

Bir konuma karar vermeden önce, her aday konumdaki deneme örneğine karşı aynı testi çalıştırın. VPS kıyaslaması için tam yöntem, ağın yanı sıra disk ve CPU performansını da kapsar; böylece seçiminizi yalnızca gecikme süresine göre yapmamış olursunuz.

New York adresi ile başka neler değişir

İlk olarak fiyat değişir. New York metrosunda güç ve zemin alanı maliyetleri, Teksas veya Orta Batı'ya göre daha yüksektir; bazı sağlayıcılar bunu konuma özel ek ücret olarak yansıtırken, bazıları ise tüm filo genelinde ortalamaya yayar. Ağustos 2026 itibarıyla tek bir kural bulunmamaktadır; bu nedenle bir ceza olduğunu varsaymadan önce, sağlayıcının kendi sipariş sayfasında aynı teknik özellikleri iki farklı konum için fiyatlandırın. Bir VPS'in aylık gerçek maliyeti nedir faturanın geri kalanını kapsamaktadır.

Hukuk, sunucuyu takip etmez. New York'un SHIELD Act düzenlemesi, verinin nerede tutulduğuna bakılmaksızın, bir New York sakinine ait özel bilgileri elinde bulunduran herkes için ihlal bildirimi ve makul güvenlik önlemleri alma yükümlülüğü getirir. Sunucunuzu Dallas'a taşımak bu yükümlülüğü ortadan kaldırmaz, Manhattan'a taşımak ise bu yükümlülüğü yaratmaz. Aynı durum GDPR (genel veri koruma yönetmeliği) ve Avrupalı kullanıcılarınız için de geçerlidir. Konum, bir sözleşme veya sektör kuralı belirli bir ülkeyi işaret ettiğinde önem kazanır; bu durum sağlık hizmetleri ve bazı finansal hizmetlerde yaygındır.

Güç ve sel riski ayrı bir paragrafı hak eder. Ekim 2012'de Hurricane Sandy vurduğunda, bodrum katındaki yakıt pompaları sular altında kaldığı ve üst katlardaki jeneratörlerin yakıtı tükendiği için Lower Manhattan'daki birçok taşıyıcı binası hizmet dışı kalmıştır. Herhangi bir metropoldeki tek bir tesis, tek bir hata noktasıdır. Yedeklerinizi farklı bir güç şebekesinde tutun ve geri yüklemenin çalıştığından emin olmak için en az bir kez başka bir yerde geri yükleme yapın.

FAQ

New York merkezli bir VPS, Avrupa'daki kullanıcılar için merkezi ABD'deki bir VPS'ten daha mı hızlıdır?

Evet, hem de öngörülebilir bir oranda. New York metropolü ile Londra arasındaki mesafe yaklaşık 78 ms'dir; bunun nedeni transatlantik kabloların New Jersey kıyısına ve Long Island'a çıkış yapmasıdır. Dallas'taki bir sunucu Londra'ya ulaşmak için önce doğu kıyısına gitmek zorundadır, bu yüzden Dallas-New York arasındaki yaklaşık 38 ms'lik ek gecikmeyi de üstlenir. Eğer tek bir makine hem ABD'nin doğusuna hem de Avrupa'ya hizmet verecekse, New York maliyeti en düşük olan uzlaşma noktasıdır.

"New York" VPS'im neden aslında New Jersey'de?

Çünkü zemin alanı ve güç kapasitesi orada bulunmaktadır. 60 Hudson Street gibi Manhattan binaları büyük işlem merkezlerinden ziyade ara bağlantı noktalarıdır; bu nedenle sunucu kabinleri Secaucus, Weehawken, Carteret, Piscataway veya Newark'ta yer alır. Ekstra fiber kablo mesafesi bir milisaniyenin çok altında bir gecikme ekler ve hiçbir web iş yükü bunu fark etmez. Belirli bir binadaki belirli bir ağa doğrudan fiziksel bağlantı (cross-connect) kurmanız gerekmedikçe tam tesis konumunu sorgulamanıza gerek yoktur.

Gecikmenin gerçekten sorunum olup olmadığını nasıl anlarım?

curl zamanlama dökümünü çalıştırın ve çıkarma işlemi yapın. time_appconnect ile time_starttransfer arasındaki boşluk, bir ağ gidiş-dönüş süresi (round trip) ile sunucunuzun kendi işlem süresinin toplamıdır. Eğer bu boşluk ping ile ölçtüğünüz gidiş-dönüş süresinden çok daha büyükse, gecikme uygulamanızın içindedir ve daha yakın bir veri merkezi bunu çözmeyecektir. Eğer boşluk bir gidiş-dönüş süresine yakınsa ve sayfa hala yavaş geliyorsa, sayfanın ardışık olarak kaç istekte bulunduğunu sayın; çünkü her bir istek gidiş-dönüş süresini tekrar öder.

New York'ta barındırma yapmak, hangi gizlilik yasalarının geçerli olduğunu değiştirir mi?

Çoğunlukla hayır. New York'un SHIELD Act yasası veya GDPR gibi kurallar, diskin nerede döndüğüne değil, verinin kime ait olduğuna göre belirlenir. Sunucu konumu, bir sözleşme veya sektörel kural belirli bir ülkeyi şart koştuğunda belirleyici faktör haline gelir; bu durum sağlık hizmetlerinde ve finansal hizmetlerin bazı bölümlerinde sıklıkla yaşanır. Bir konumu seçmeden önce ilgili gereksinimin metnini mutlaka okuyun.

Bir CDN, iyi konumlandırılmış bir VPS'in yerini tutabilir mi?

Statik dosyalar için evet. Bir CDN (içerik dağıtım ağı), görselleri ve betikleri kullanıcılarınızın yakınında önbelleğe alır ve bu istekler için mesafenin çoğunu ortadan kaldırır. Ancak oturum açılmış bir paneli veya veritabanına yapılan bir yazma işlemini önbelleğe alamaz; bunlar yine de ana sunucunuza (origin) kadar gitmek zorundadır ve tam gidiş-dönüş süresini öder. Ana sunucuyu veri girişi yapan kullanıcıların yakınına yerleştirin ve geri kalanını CDN'in yönetmesine izin verin.