Game Server İçin VDS Seçerken 9 Kriter (Net Karşılaştırma)

Game server kurarken “en ucuz VDS” yerine “oyun deneyimini bozan darboğazı” hedeflemek gerekir. FPS/RTT (round-trip time) gecikmesi, paket kaybı, CPU kuyrukları ve disk gecikmesi (özellikle anlık dünya verisi/harita yükleme) doğrudan hissedilir. Bu rehberde VDS alırken 9 kritik kriteri, ölçüm metrikleriyle ve karar akışıyla anlatıyorum. Okuduktan sonra hangi spec’in neden gerekli olduğunu netleştirip sağlayıcı karşılaştırmasını standartlaştıracaksınız.

## 1) Oyunun ağ modeli: “latency mi, throughput mu?”

Game server seçiminin ilk ayrımı oyunun ağ davranışıyla yapılır. Aynı bant genişliği farklı oyunlarda farklı sonuç verir; çünkü paket sıklığı, senkronizasyon ve yeniden iletim (retransmit) değişir.

Hızdan önce gecikme (latency)

• Öncelik: RTT, jitter (gecikme dalgalanması), paket kaybı
• Belirti: “Hep var” gibi görünen kayma/teleport, düzensiz hit algısı

Trafikten önce kararlılık (throughput yerine packet handling)

• Öncelik: toplam banttan çok, eşzamanlı bağlantı ve paket işleme
• Belirti: kalabalık maçlarda gecikmenin aniden artması

NetKıyas gibi karşılaştırma sitelerinde ürün sayfasında şu ayrıntıları arayın: - Sunucunun Türkiye lokasyonuna/peering’e yakın olması - Çeşitli saatlerde anlık yükselme yapan “oversubscription” şüphesi (net ölçüm olmadan varsayım yapmayın)

Pratik: Aynı CPU/RAM’a sahip iki VDS’den biri oyun içi gecikmede 10-20 ms daha iyi oluyorsa, bu fark çoğu zaman fiziksel CPU değil ağ topolojisidir.

## 2) CPU mimarisi ve single-core performans

Çoğu game server (özellikle tick tabanlı) yükün önemli kısmını tek çekirdeğe veya az çekirdeğe yığar. Bu yüzden “toplam core sayısı” yerine tek çekirdek performansı belirleyicidir.

Hangi metrikleri hedefleyin?

• Single-core performans (bench sonucu varsa kullanın)
• Çalışma sırasında CPU steal değerleri (paylaşımlı altyapı kaynak çatışması)
• Oyun motoru/servis tarafında tick sürelerinin stabil kalması

Kontrol yöntemi (kısa checklist)

• Sağlayıcının VDS ürününde vCPU tipi (ör. Intel/AMD jenerasyon) ve CPU oversubscription yaklaşımı belirtiliyor mu?
• VDS panelinde CPU kullanımı yanında “steal”/kuyruk gibi ayrıntılar görülüyor mu?

Net öneri: 64 kişilik bir sunucu için 8 vCPU yerine “daha yüksek tek çekirdek” yaklaşımını seçin; bu, tick sürelerini daha stabil tutar.

## 3) RAM: “kaç oyuncu + kaç mod” denklemi

RAM, doğrudan gecikmeyi değil; çoğu durumda disk swap veya çöp toplama (garbage collection) gibi ikincil gecikmeleri etkiler.

RAM’in oyun server’da rolü

• Dünya/harita önbelleği, varlık (assets) belleği
• Plugin/mod sistemlerinde bellek tüketimi
• Cache + log birikimi

Net hesap yaklaşımı

• 1) Oyunun referans spec’ini temel alın
• 2) Ek mod/plugin ekledikçe RAM artışını hedefleyin
• 3) İlk kurulumdan sonra 24 saat performans verisi toplayın

Özellikle JVM/Node.js tabanlı ek servisler (panel, web API, RCON arayüzü) varsa RAM’i minimumdan seçmeyin.

## 4) Disk tipi ve IOPS: başlangıç değil, “anlık işlemler”

SSD/VDS disk seçimi sadece “dosya yükleme hızı” değildir. Game server’da sık görülen anlık disk işlemleri: - Harita/asset paketi açma - Snapshot/rollback anları - Veri kaydı (banlist, leaderboard, economy)

IOPS neden kritik?

• Çok küçük dosyalar ve sık yazma olduğunda IOPS farkı hissedilir
• Disk gecikmesi (latency) artınca tick süreleri uzar

Pratik hedef

• Ürün açıklamasında “NVMe SSD” ifadesi varsa bu ilk işarettir
• IOPS/latency değerleri paylaşılmıyorsa, en azından sağlayıcının disk mimarisini netleştirin

NetKıyas’ta “IOPS” doğrudan belirtiliyorsa bunu veri olarak alın; belirtilmiyorsa aynı fiyata denk gelen seçenekleri kıyaslarken diskin türü üzerinden ayrım yapın.

## 5) Ağ bant genişliği: “GB/s değil, paket davranışı”

Bant genişliği (bandwidth) tek başına yeterli değildir; ama yine de temel eşiklerin altına inmemek gerekir.

Oyunlarda bant genişliği nasıl tüketilir?

• Oyuncu sayısı arttıkça gönderilen/alınan paket sayısı katlanır
• Büyük haritalar ve sürekli event’ler paket hacmini artırır

Seçim sırasında bakılacak noktalar

• Paket kaybı toleransı (daha çok ağ kalitesiyle ilgilidir)
• Trafik limitleri veya “fair use” sınırları
• Eğer sağlayıcı “unmetered” diyorsa, bunu pratikte test edecek yönteminiz olmalı

Eğer oyunda kalabalık anlarda gecikme artıyorsa, çoğu zaman bant genişliğinden önce “oversubscription / queueing” kaynaklı paket birikmesi yaşanır.

## 6) Lokasyon ve peering: oyuncunun Türkiye’de nerede olduğu

Türkiye içi oyuncularla oynanan çoğu oyunda lokasyon farkı, CPU/RAM farkından daha hızlı sonuç verir.

Lokasyon seçimi

• Sunucu bölgesi: Türkiye’ye daha yakın DC (data center) yerine aynı peering kalitesine sahip rota tercih edilir
• CDN gerekmez; fakat oyun trafiğinde “yol kalitesi” kritik olur

Ölçüm yapma yöntemi

• Sunucu kurulumundan önce ping/jitter ölçümü yapın (ör. geçici kurulumla)
• Mümkünse sağlayıcının benchmark/Test sunucusu veya geçmiş deneyim verisi paylaşmasını isteyin

Net karar için kural basittir: Oyuncu kitleniz ağırlıkla Türkiye ise, “Türkiye çıkışlı” ve istikrarlı ağ raporu olan seçenekleri öne alın.

## 7) Trafik şeffaflığı: DDoS koruma, RCON ve yönetim portları

Game server yönetimi için RCON/SSH/Web panel gibi portlar vardır. Burada iki risk oluşur: - Sunucunun saldırı altında yavaşlaması - Yönetim portlarının yanlış güvenlik ayarıyla açık kalması

Kontrol listesi

• Sağlayıcıda DDoS koruma katmanı var mı?
• Firewall yönetimi: panelden mi yoksa OS düzeyinde mi yönetiliyor?
• Fail2ban / rate limit entegrasyonu gibi otomasyonlar mevcut mu?

DDoS korumayı “var” diye değil, “hangi trafik tipini nasıl temizliyor” diye değerlendirin. Özellikle UDP tabanlı oyunlarda yanlış koruma modeli performansı düşürebilir.

## 8) Yedekleme (backup) ve geri dönüş süresi (RTO)

Game server’da yedekleme yalnızca dosya kopyalamak değildir. Kayıp sonrası geri dönme süresi (RTO) oyuncu deneyimini etkiler.

Hangi yedekleme tipi gerekli?

• Otomatik yedekleme: planlı ve düzenli
• Elle tetiklenen yedek: güncelleme/mod değişiminden önce
• Dosya + veri: world/region dosyaları ve ekonomi/oyuncu verisi gibi veri tabanları

Net değerlendirme kriterleri

• Yedek sıklığı (ör. 1 saat/6 saat/gün)
• Saklama süresi (kaç gün)
• Geri yükleme yöntemi: panelden tek tık mı, yoksa yönetim komutuyla mı?
• Yedeklerin lokasyonu: aynı sunucu üzerinde mi, dış depolamaya mı gidiyor?

İyi senaryo: Yedek dosyaları ayrı bir depolama alanında tutulur; aynı fiziksel arıza durumunda kayıp azalır.

## 9) Ölçeklenebilirlik: mod artınca server’ı “yeniden kurmadan” büyütün

Oyuncu arttıkça sadece CPU/RAM yetmez; aynı zamanda yönetim, otomasyon ve taşımayı planlamak gerekir.

Ölçeklenebilirlikte pratik sorular

• Aynı VDS üzerinde kaynak artırma (vertical scaling) var mı?
• Disk kapasitesi artırılabiliyor mu?
• İmaj/kopya alma ile güncelleme test edilebilir mi?

En doğru yaklaşım: staging ile güncelleme

Mod/oyun güncellemelerini doğrudan prod sunucuya uygulamak yerine: 1) Staging ortamı (test sunucusu) kur 2) Güncellemeyi 1-2 saat dene 3) Ardından prod’a uygula

Bu yöntem, hatalı bir update yüzünden gece sunucunun düşmesini engeller.

Karşılaştırma tablosu: VDS seçimini netleştiren kriterler

Aşağıdaki tablo, game server için VDS değerlendirirken “hangi başlıkla neyi ölçmeniz gerektiğini” özetler.

Kurulumdan sonraki ilk 30 dakika: doğru seçimi doğrulama

VDS’i satın aldıktan sonra seçim kalitesini “hemen” test edin. Amaç, aylar sonra fark etmek değil.

1) Basit servis sağlığı

• Oyun server servisinin loglarında hata var mı?
• CPU/RAM normal sınırda mı?
• Disk kullanımında olağan dışı yazma var mı?

2) Ağ ölçümü

• Oyuncuların yaşadığı ilk RTT/jitter değerlerini karşılaştırın
• Aynı gün içinde (pik saat) tekrar bakın

3) Kaydetme ve yükleme denemesi

• Harita/region yüklemelerini başlatın
• Veri kaydı yapan işlemleri tetikleyip disk spike var mı kontrol edin

Bu üç adım, “spec güzel görünüyor ama oyun akmıyor” durumunu hızlı ayıklar.

Sonuç: Satın alma kararını 9 kriterle sabitleyin

Game server için VDS seçerken tek bir özelliğe odaklanmak yerine CPU tek çekirdek, RAM kapasitesi, disk latency/IOPS, ağ kalitesi ve yedekleme RTO dengesini kurun. İlk kurulum sonrası 30 dakikada CPU/RAM-disk spike ve RTT/jitter verisi toplayın; uyuşmayan parametreleri değiştirin. Aksiyon planı: Önce 9 kriterin her birine göre kısa bir kontrol listesi oluşturun, sonra sağlayıcılar arasında tabloyla ayrım yapın ve en son olarak pik saat testini standartlaştırın.