Vultr High Frequency vs Hetzner Cloud: Performans ve Maliyet Kıyas Rehberi

Sunucu seçimi yaparken yalnızca “daha hızlı sunucu” ifadesine bakmak yanıltıcıdır. Çünkü ağ gecikmesi (latency), vCPU gerçeği (burst/steady), depolama diski karakteri, trafik ve alan kullanımı maliyeti doğrudan etkiler. Bu yazıda Vultr High Frequency (VHF) ile Hetzner Cloud’u; performans göstergeleri, pratik maliyet kalemleri ve hangi senaryoda hangisinin daha mantıklı olduğuna göre kıyaslayacaksınız.

Hedefimiz; benchmark grafikleri yerine, NetKıyas kullanıcılarının günlük tasarım kararlarında işine yarayan net bir seçim çerçevesi vermek. Ayrıca her iki taraf için “hangi ölçümü nasıl kontrol etmeli” kısmını da ekliyoruz.

1) Farkın kaynağı: VHF neyi hedefler, Hetzner neyi optimize eder?

Vultr High Frequency (VHF) yaklaşımı

Vultr High Frequency, “CPU ağırlıklı” işlerde daha yüksek çalışır sürekliliği ve düşük gecikmeyi hedefler. Uygulamada beklenen sonuç genellikle şunlardır: - CPU sık kullanan servislerde (web uygulaması, yoğun cache isabeti, bazı oyun server işleri) daha tutarlı yanıt - Ağ tarafında iyi performansla birlikte kısa iş parçacıklarında (thread) daha stabil tempo - Ölçeklenebilirlik için dikey/horizontal planlara göre hızlı yükseltme/düşürme

Burada kritik nokta: VHF, her iş yükü için “her zaman en ucuz” seçenek değildir. En iyi sonucu; CPU’nun darboğaz olduğu ve gecikmenin doğrudan kullanıcı deneyimine etki ettiği senaryolarda verir.

Hetzner Cloud yaklaşımı

Hetzner Cloud ise daha “maliyet/kapasite dengesi” odaklıdır. Bulut altyapısında genelde: - Depolama maliyeti ve genel kaynak başına değer - İstikrarlı performans - Kurumsal kullanım için operasyonel rahatlık (yedekleme, ölçekleme, erişim yönetimi)

Hetzner tarafında performans gerçekliği, planın CPU/ram oranı ve disk türüyle birlikte daha “paketlenmiş” bir karakter taşır. Bu nedenle seçim yaparken “tek ölçüm” yerine uygulama profilinizin bu pakete uyup uymadığını incelemek gerekir.

2) VCPU, RAM ve disk: Planı seçerken bakılacak 6 somut parametre

Aşağıdaki liste, iki sağlayıcı arasında kıyas yaparken her zaman kontrol edilmesi gereken maddeleri verir. Benchmark sayfası yerine doğrudan karar kriterine dönüşür.

Karşılaştırma kontrol listesi

• vCPU tipi ve süreklilik: “Burst” mantığı varsa, yoğun dönem sonrası performans düşüşü olabilir.
• RAM/CPU oranı: CPU hızlı olsa bile bellek yetersizse swap/GC maliyeti artar.
• Disk sınıfı ve IOPS karakteri: DB yazma ağırlıklı işlerde disk karakteri belirleyicidir.
• Network throughput: Tek seferlik hızdan çok, sürekli yük altında bant genişliği ve paket kaybı önemlidir.
• İn/out trafik (egress) maliyeti: Bulut maliyetini en çok egress kalemi değiştirir.
• Fiyatın dahil ettiği servisler: yedek (backup), ek IP, snapshot, kontrol paneli/erişim gibi kalemler paket dışı kalabilir.

3) Maliyet kıyası: Benzer kullanımda nasıl daha doğru hesap yapılır?

“Hangisi daha ucuz?” sorusu, tek başına anlamlı değildir. Bulut maliyetinde değişken üç kalem öne çıkar: (1) saatlik/aylık kaynak, (2) trafik (özellikle egress), (3) yedekleme ve ek hizmetler.

Somut bir maliyet iskeleti (kopyala-kullan)

Aşağıdaki iskeletle iki sağlayıcıyı aynı senaryoda kıyaslayın:

• Uygulama VM boyutu: (ör. 4 vCPU / 16 GB RAM)
• Aylık saat: 730 saat
• Egress: ör. 1 TB/ay
• Yedekleme: “dahil mi / ayrı mı”
• Ek IP: varsa dahil mi

Sonuçta maliyet şöyle çıkar: 1. Kaynak maliyeti = plan fiyatı x (730) 2. Trafik maliyeti = (aşım varsa) egress tarifesiyle 3. Operasyonel ekler = snapshot/backup/ek IP

NetKıyas pratik kuralı: Kullanıcıların sık yaptığı hata, ilk aylık kaynak fiyatını tek referans almak. Egress ve backup ayrı ise, iki sağlayıcı arasındaki fark ilk izlenimin tam tersine dönebilir.

“VHF mi Hetzner mı?” finansal seçim kuralı

• CPU darboğazı netse ve uygulama gecikmeye duyarlıysa, VHF’nin ek maliyeti genellikle daha hızlı “performans kazanımı” olarak geri döner.
• CPU darboğazı değilse; daha çok depolama/kapasite/ortalama trafik söz konusuysa Hetzner Cloud çoğu zaman daha dengeli bir toplam maliyet çıkarır.

4) Performans kıyası: Benchmark yerine ölçülebilir testler

İki sağlayıcıda “hızlı” sonucu görmek için tek yöntem benchmark tablosu değildir. Daha güvenilir yaklaşım, uygulamanızın yaptığı gerçek işi simüle etmektir.

Uygulama odaklı test planı

Aşağıdaki mini test dizisiyle 30-60 dakikada kıyas çıkarabilirsiniz:

H3) 1. TLS + sayfa yanıtı

• Aynı uygulama kodu
• Aynı cache stratejisi (ör. Nginx cache veya uygulama cache)
• Aynı bölge/POP

Ölçüm: - İlk istek gecikmesi (TTFB) - 50. ve 95. yüzde dilim (p95) yanıt süreleri

H3) 2. CPU sıkışma testi

• Uygulamada CPU yoğun endpoint’i 1-2 dakika yükle
• Aynı yükte p95 gecikmeyi karşılaştır

Beklenen fark: - VHF tarafında CPU odaklı kısım daha stabil görünebilir. - Hetzner tarafında yine iyi performans alınabilir; ancak “CPU darboğazı” belirgin değilse bu avantaj görünmeyebilir.

H3) 3. Disk yazma/okuma testi (DB kullanıyorsanız şart)

• Basit bir DB migration sonrası okuma/yazma karışımı test edin
• Log yazımı ve index güncellemeleri gecikme yaratır mı bakın

Trafik altında performans

Aynı VM boyutuyla: - aynı kullanıcı profili - aynı istek boyutları - aynı dosya boyutu (ör. 100 KB görsel vs 2 MB görsel)

Trafik arttıkça CPU, disk ve ağın birlikte etkisi ortaya çıkar. Bu nedenle “tek kullanıcı testi” ile karar vermeyin.

5) Hangi senaryoda hangisi? Net seçim matrisi

Aşağıdaki matris, karar vermeyi hızlandırmak için yazıldı. Senaryonuz hangisine daha yakınsa o seçeneği ilk sıraya koyun.

6) Operasyonel farklar: Yedekleme, ölçekleme ve yönetim

Performans kadar “işin devam etmesi” de önemlidir. Bu bölümde karar verirken pratik etkisi olan farklara odaklanıyoruz.

Yedekleme (backup) ve kurtarma planı

• Otomatik yedekleme dahil mi?
• Snapshot/restore süresi gerçek kullanımda ne kadar sürer?
• DB için (özellikle) tutarlı yedek alma senaryosu var mı?

NetKıyas yaklaşımı: Küçük sitelerde bile 30-60-90 gün ölçekli bir disaster recovery planı yapılır. Aynı VM’lerde provider farkı yedekleme kalitesinde ortaya çıkar; bu yüzden “disk alanı” kadar yedek prosedürü de hesaba katın.

Ölçekleme ve bakım pencereleri

• CPU/RAM artırma işlemi ne kadar sürer?
• Plan değişikliği sonrası performans tutarlılığı bozulur mu?
• Ağ değişikliği (IP/route) uygulamanızı etkiler mi?

Burada VHF’nin “hız hedefi” avantajı, doğru plan değişim stratejisiyle birleştiğinde net değer üretir. Hetzner tarafında da ölçekleme genelde pratiktir; ancak hedefiniz CPU sıkışmasını aşmaksa VHF’yi daha erken test edin.

Kontrol paneli ve erişim yönetimi

• SSH key yönetimi (şifre tabanlı erişimi kapatacak ayarlar)
• Erişim logları ve role dayalı yönetim
• Güvenlik güncelleme rutinleri (otomatik mi manuel mi)

Bu başlıklar, “performans farkı var mı yok mu” sorusundan bağımsızdır; sistemin sürdürülebilirliğini etkiler.

Sonuç: Kararı testle netleştirin, ilk sırayı senaryonuza göre belirleyin

Vultr High Frequency ile Hetzner Cloud arasında doğru seçimi yapan ölçüt “genel hız” değil; uygulamanın CPU/disk/ağ profilidir. CPU darboğazı belirginse, gecikme (p95/TTFB) kritikse ve gerçek zamanlı jitter istemiyorsanız Vultr High Frequency’ı ilk sıraya alın. CPU darboğazı olmayan, daha çok kapasite/denge ve toplam maliyet hedefleyen senaryolarda Hetzner Cloud çoğu durumda daha mantıklı bir toplam çıkarır.

Aksiyon önerisi: Aynı uygulama senaryosunu iki sağlayıcıda da kurun, 45-60 dakikalık ölçümle p95 yanıt + CPU sıkışma + (DB varsa) disk yazma/okuma testlerini karşılaştırın. Bu test sonuçlarına göre VM boyutunu ve egress/yedekleme kalemlerini aynı modelle hesapladığınız anda karar netleşir.