Vultr High Frequency vs Hetzner Cloud: Net performans karşılaştırması

VPS/VDS gibi “aynı görünen” bulut sunucularda bile performans farkı; CPU mimarisi, depolama türü, ağ (network) kalitesi ve sanallaştırma mimarisinden gelir. Bu yazıda Vultr High Frequency ile Hetzner Cloud arasındaki farkları “soyut kalite” yerine; gecikme, bant genişliği, disk davranışı ve maliyet/performans üzerinden netleştiriyoruz. Ayrıca hangi iş yüklerinde birinin diğerine göre belirgin avantaj sağladığını, hangi durumlarda ise iki tarafın da “eşit” sayılacağını adım adım ortaya koyuyoruz.

1) Ne satın aldığınızı doğru anlayın: Hangi katman optimize?

Her iki sağlayıcı da bulut sunucu sunar; ancak odak alanları farklıdır.

Vultr High Frequency (HF) neyi hedefler?

Vultr’un High Frequency paketleri, özellikle düşük gecikme (latency) ve daha stabil işleme süresi hedefiyle konumlandırılır. Bu paketlerde amaç genellikle: - Ağ/işlem hattında kuyruklanmayı azaltmak - CPU zaman dilimlerini daha “tahmin edilebilir” hale getirmek - Çok küçük işlem süreleriyle çalışan iş yüklerini daha iyi beslemek

Pratikte bu, tipik olarak: - API çağrıları - Cache araması sonrası hızlı yanıt üreten katmanlar - Düşük gecikmeli trading altyapıları (tam “garanti” değil, ölçümle doğrulanır)

Hetzner Cloud neyi öne çıkarır?

Hetzner Cloud, çok yaygın ve tutarlı bir şekilde maliyet/performans ve operasyonel rahatlık odağında bilinir. Hetzner tarafında genelde: - Ünite maliyeti başına performans - Disk/IO davranışının iş yüklerine göre net okunması - Yönetilebilirlik öne çıkar.

Not: Hetzner Cloud tarafında “High Frequency” gibi özel bir isimlendirme yoktur; bunun yerine sunucu tipleri (CPU/RAM/disk) ve bölge seçimi üzerinden performans elde edilir. Bu yüzden doğru kurulum ve doğru boyutlandırma kritik rol oynar.

2) Gecikme ve jitter: “Hız”tan fazlası

Düşük gecikme, tek başına “daha hızlı” demek değildir; aynı zamanda jitter (gecikmenin dalgalanması) kritik olur. Trading, gerçek zamanlı işleme, bazı mesajlaşma senaryoları ve sık etkileşimli API’ler jitter’a hassastır.

Net karşılaştırma yaklaşımı

Aşağıdaki testleri kurulumdan sonra aynı koşullarda yapmadan karar vermek eksik kalır. Yine de karar kriterini önceden belirleyebilirsiniz.

Ölçmeniz gereken 4 metrik

İlk paket gecikmesi: ping (ICMP) ile kaba fikir
TCP bağlantı kurulumu: curl -w ile TLS/TTFB gözlemi
Gerçek uygulama gecikmesi: kendi endpoint’inizde A/B
Disk IO jitter’ı: kısa süreli küçük dosya yazma/okuma testi

“HF her zaman daha iyidir” kural değil

Vultr HF düşük gecikmeyi hedefler; ancak şu durumlarda avantaj görünmeyebilir: - Uygulama asıl darboğazı CPU değilse (ör. veritabanı kilidi veya dış servis gecikmesi) - İş yükü büyük transferler ve yüksek bant genişliği gerektiriyorsa - Disk tabanlı süreçler (özellikle küçük dosya/çok sayıda okuma) baskınsa

Bu yüzden “HF aldım, kesin daha hızlı olur” yerine, kapsayıcı ölçüm yapın.

3) Depolama ve IO davranışı: Performansın gizli kaynağı

Bulut sunucularda gecikmenin bir bölümü CPU’dan gelir; önemli bir bölümü de disk IO ve dosya sistemi davranışından gelir.

Küçük IO ağırlıklı işlerde kontrol listesi

Şu iş yükleri disk/IO hassastır: - Veritabanı (özellikle küçük işlemler ve sık commit) - Cache yerine dosya tabanlı session saklama - Logların hızlı ve sık yazıldığı sistemler

Bu noktada Vultr HF, “düşük gecikme” hedefli olduğu için bazı senaryolarda avantaj sağlayabilir; fakat Hetzner Cloud tarafında da doğru disk/konfigürasyon seçimiyle benzer sonuç alınabilir.

Net karar kuralı

Uygulamanızın p99 (kuyrukta en yavaş yüzde 1) değerini belirleyen şey CPU süresi ise HF öne çıkar.
p99’u belirleyen şey disk IO/lock ise “HF ismi” tek başına yeterli değildir; disk türü ve VM tipi seçimi belirleyicidir.

4) Bant genişliği ve network throttling: Süreklilik mi yoksa zirve mi?

Birçok kişi “bant genişliği”ni tek sayı sanır; oysa pratikte daha önemli olan: - Trafiğin nasıl şekillendiği (burst) - Uzun süreli yükte nasıl davrandığı - Sağlayıcının sistem güvenliği/denge politikaları

Bu nedenle aşağıdaki mantıkla değerlendirin: - Kısa sürede çok istek: burst performansı - Gün boyu sürekli yük: sürdürülebilir throughput - Dönemsel yoğunluk: throttling/jitter etkisi

Net öneri: Aynı süre ve aynı yük altında 30-60 dakika test yapın. 10 dakikalık testler “yanıltıcı derecede iyi” sonuç verebilir.

5) Maliyet/performans: Saatlik değil, birim iş maliyeti

Bulut sunucularda fiyat etiketi değil; “aynı işi kaç saniyede kaç TL’ye yaptım?” sorusu net sonucu verir.

Birim maliyet hesabı (pratik formül)

Sunucu maliyeti: saatlik fiyat x kullanım saati
Performans ölçümü: işin tamamlanma süresi (ör. 10.000 istek p95)
Birim maliyet: toplam maliyet / tamamlanan iş sayısı

Bu yaklaşımı iki sağlayıcıya da uygulayın. Sonuç şu şekilde netleşir: - HF paketleri daha pahalı olabilir; ancak p95/p99 ciddi iyileşiyorsa birim maliyet düşer. - Hetzner Cloud daha ucuz olabilir; ancak performans farkı küçükse birim maliyet Hetzner lehine döner.

Kapalı form tahmin değil, açık test

Tek bir URL’den “şu kadar hızlı” gibi beklenti kurmak yerine, kendi endpoint’inizde şu şekilde test edin: - Aynı kod versiyonu - Aynı veritabanı şeması - Aynı cache ayarları - Aynı kullanıcı yük profili

6) Senaryo bazlı net eşleştirme

Aşağıdaki tablo “hangi iş yükünde hangisi daha mantıklı?” sorusuna hızlı cevap verir.

İş yükü / hedef	Daha olası avantaj	Neden
Çok düşük p99 gecikme (in-memory iş + hızlı yanıt)	Vultr High Frequency	HF’nin gecikme hedefi ve daha kararlı zamanlama beklentisi
Genel API trafiği + maliyet kontrolü	Hetzner Cloud	Maliyet/performans dengesi ve kolay ölçek
Disk IO yoğun (DB çok sık commit, çok sayıda küçük işlem)	Konfigürasyona bağlı	IO türü ve VM seçimi belirleyici; HF adı tek başına yetmez
Sürekli yüksek throughput (dosya/stream)	Konfigürasyona ve ağ limitlerine bağlı	“Zirve” değil “sürdürülebilir” performans önemli
Otomatik ölçek + çok sayıda küçük node	Hetzner Cloud (genelde)	Operasyonel basitlik ve birim maliyet avantajı
CPU-bound (yüksek işlem + sık thread)	Vultr HF veya Hetzner (tip seçimiyle)	CPU mimarisi ve VM tipi birlikte etkiler

7) Operasyonel gereksinimler: İzleme, bakım, yedekleme

Performans kadar operasyon da “toplam kaliteyi” belirler. Bir sağlayıcıyı seçtiğinizde aşağıdaki maddeler net plan gerektirir.

İzleme (monitoring) ve log çıktısı

Uygulama p95/p99 ölçümü: APM ya da uygulama düzeyinde metrik
Sistem metrikleri: CPU steal, iowait, network packet rate
Anomali tespiti: anlık spike’larda hangi katmanın geciktiğini ayırın

Yedekleme (backup) ve geri dönüş planı

Veritabanı için ayrı yedek stratejisi
Dosya tabanlı birimlerde snapshot/persist planı
“Geri yükleme süresi”ni de test edin (sadece yedek almak yetmez)

Bölge (region) seçimi

Türkiye kullanıcı tabanınız varsa, en az gecikme aldığınız bölgeyi seçin. Region seçimi, sağlayıcı ismi kadar fark yaratabilir.

8) Net seçim rehberi: 30 dakikada karar taslağı çıkarın

Aşağıdaki akış, “hangi tarafa yönelmeliyim?” sorusuna hızlı taslak çıkarır.

Adım adım

Uygulamanızın darboğazını belirleyin: CPU mu, disk mi, ağ mı?
Her iki sağlayıcıda da aynı mimariye yakın VM tipini seçin (CPU/RAM oranını mümkün olduğunca benzer tutun).
Aynı metrik setiyle test edin: - p95/p99 endpoint süresi - eş zamanlı istek altında hata oranı - iowait ve disk gecikme göstergeleri
30-60 dakika boyunca sabit yük altında gözlem yapın.
Birim iş maliyeti hesabını tamamlayın (saatlik maliyet + tamamlanan iş).

Tek satırlık sonuç kuralı

Uygulamanızın gecikmesi p99 ile belirleniyorsa ve CPU/az IO ile hızlı yanıt hedefliyorsanız Vultr High Frequency daha güçlü adaydır.
Uygulamanızın performansı kabul edilebilir aralıkta kalıyor ve p99 farkı sınırlıysa Hetzner Cloud çoğu zaman daha rasyonel maliyet çıkarır.

Sonuç olarak, Vultr High Frequency ile Hetzner Cloud arasında “genel bir kazanan” aramak yerine; p95/p99, iowait, ağ sürekliliği ve birim iş maliyeti kriterleriyle 2 tur ölçüm yapın. Önce 30-60 dakika testle darboğazı bulun, sonra seçimle maliyetinizi sabitleyin. Net ve sürdürülebilir bir kurulum için ölçüm sonuçlarını yazılı hale getirmeniz kararınızı kalıcılaştırır.