Time4VPS ve BlueVPS gibi düşük maliyetli VPS’lerde net seçim rehberi

Düşük maliyetli VPS sağlayıcıları (ör. Time4VPS, BlueVPS gibi) özellikle yeni başlayanların bütçesini rahatlatır. Ancak düşük fiyat çoğu zaman aynı kaynağın herkesle paylaşıldığı, kısıtların daha sıkı uygulandığı veya destek süreçlerinin farklı çalıştığı anlamına gelebilir. Bu yazıda, “ucuz VPS alınır mı?” sorusunu tek tek test kriterlerine çevirip bütçenize uygun, riski ölçülebilir bir karar çerçevesi kuracaksınız. Ayrıca sağlayıcıdan sağlayıcıya değişen “overselling”, bant genişliği davranışı, disk hızı ve ağ kalitesi gibi noktalarda net kontrol listesi bulacaksınız.

1) Düşük maliyetli VPS’te fiyatı belirleyen 6 somut kalem

Ucuz VPS’ler genellikle aşağıdaki kalemlerde tasarrufa gider. “Fiyat düşükse sorun mu var?” yerine, “hangi bileşen hangi bedeli ödüyor?” sorusunu sorun.

CPU (vCPU) tahsisi: garanti mi oversell mi?\nVPS paketlerinde görünen vCPU sayısı tek başına yeterli değildir. Şu fark yaratır:

• Burst (anlık yükseltme): Belirli süre yüksek performans verip sonrasında sınırlamak.
• Paylaşımlı CPU: Aynı fiziksel ana makineyi çok sayıda VPS kullanır; yoğunlukta performans dalgalanır.
• CPU limit / cap: Saat başı ortalama veya anlık üst sınır.

Net kontrol: Paket sayfasında “dedicated CPU” gibi ibare varsa bu daha farklıdır. Yoksa, fiyat avantajı genellikle paylaşımlı/limitli CPU modelinde olur.

RAM ve OOM davranışı: yoğun işte neden ölür?

Düşük maliyetli VPS’lerde RAM aşımı olunca Out-Of-Memory (OOM) ile süreçler kesilebilir. Bu durum özellikle: - Docker konteynerleri, - Node.js/Java uygulamaları, - Redis/MariaDB gibi bileşenlerde sık görülür.

Net kontrol: Sağlayıcı yönetim paneli/knowledge base’de “OOM”, “resource limit” veya benzeri açık bir açıklama olup olmadığını arayın.

Depolama (SSD/HDD) ve disk IOPS

Performans farkının en belirgin olduğu yerlerden biridir. Aynı “SSD” ifadesi bile farklı tip SSD ve farklı IOPS limitleri anlamına gelebilir.

Net kontrol: “IOPS garanti” veya “NVMe” bilgisi yoksa, disk hızını siz ölçmelisiniz (aşağıdaki testler bölümüne bakın).

Ağ (bandwidth) ve overselling: “limit var mı yok mu?”

Düşük fiyatlı planlarda bant genişliği davranışı farklı olabilir: - Metreli trafik limiti - 1 Gbps uplink ama kontenjana bağlı hız düşüşü - Peak/avg kuralı - Overselling etkisiyle yoğun saatlerde gecikme artışı

Net kontrol: Trafik “unmetered” yazsa bile bunun bir adil kullanım politikası (fair use) veya throttle (hız kırpma) şartı olup olmadığını okuyun.

Konum/route kalitesi: Türkiye kullanıcıya giden gecikme

Türkiye’de barınan kullanıcı kitlesi için Avrupa/DC bölgelerinde bile RTT değişebilir. Düşük maliyetli VPS’lerde bazen daha uzun/kalabalık rota tercih edilir.

Net kontrol: Sağlayıcı konumlarını görün; son kullanıcı konumunuza göre gecikme (ping) ve jitter (dalgalanma) hedefleyin.

Yönetim ve destek: “ucuz” ama yönetilebilir mi?

Destek kanalı (ticket/Telegram/e-posta), ortalama dönüş süresi ve plan değişikliklerinin prosedürü de maliyete yansır.

Net kontrol: “24/7 destek” iddiası varsa SLA (hizmet seviyesi) veya ortalama süre bilgisi var mı? Yoksa bu konuda netlik yoktur.

2) Time4VPS / BlueVPS gibi sağlayıcıları seçerken net karar matrisi

Aşağıdaki matris, sağlayıcıyı “fiyat” üzerinden değil “uygulama gereksinimi” üzerinden değerlendirir.

Uygulamanıza göre hangi kriteri öne çekmelisiniz?

• Web site (WordPress/Laravel vb.): cache, disk hızı, RAM, HTTP/2, TLS, yük altında kararlılık.
• Panel/API: ağ gecikmesi, bağlantı sayısı (keep-alive), log/izleme.
• Mail hizmeti/SMTP: IP itibar (reputation), spam filter davranışı, reverse DNS.
• Otomasyon/CI: CPU dalgalanması ve disk IOPS.
• Oyun/Realtime: jitter, packet loss, routing.

Net karar tablosu

3) Satın almadan önce yapmanız gereken 4 pratik test

Bu bölüm, “paket özellikleri yazıyor ama gerçekte nasıl?” sorusunu yanıtlar. Testleri 1-2 saat içinde tamamlayabilirsiniz.

3.1 Ağ kalitesi: ping ve basit yük

Amaç: Türkiye kullanıcı kitlesi için gecikme ve kayıp var mı görmek. - 20-50 paket ile ping hedefi belirleyin. - Aynı testi gün içinde (ör. akşam) tekrar edin.

Net hedef örnekleri (uygulamaya göre değişir): - Ortalama RTT yüksekse: routing/rüzgar etkisi olabilir. - Paket kaybı varsa: realtime veya API’da sıkıntı olur.

3.2 Disk IOPS ve latency: fio ile ölçüm

Amaç: “ucuz VPS ama disk yavaş” durumunu sayıya dökmek. - 4K ve 64K gibi iki farklı senaryo ile ölçün. - Yazma ve okuma ayrı bakın.

Örnek komut (sadece fikir vermesi için): - fio --name=randread --filename=/tmp/test --size=1G --runtime=60 --bs=4k --iodepth=16 --numjobs=4 --readwrite=read --time_based

3.3 CPU davranışı: kısa yük testi

Amaç: CPU burst devreye giriyor mu yoksa sabit mi? - 10-15 dakika CPU yoğun yüklemesi yapın. - Aynı testi bir süre sonra (ör. 2-3 saat) tekrarlayın.

3.4 DB ve servis kararlılığı: gerçek uygulama senaryosu

Amaç: “teoride hızlı” ama DB altında çökmüyor mu? - Uygulamanın kullandığı DB (MariaDB/MySQL/PostgreSQL) varsa küçük bir veri seti ile yazma/okuma yapın. - Loglarda “slow query”, timeout, restart izleyin.

4) Düşük maliyetli VPS’te en sık 8 risk ve net önlemler

Bu riskleri görmezden gelmek, ucuz VPS’i “pahalı arıza”ya çevirebilir.

1) Ani throttling (hız kırpma)

Önlem: Trafik limitleri ve throttle koşullarını paket açıklamasından net okuyun. “Unmetered” ibaresi varsa fair-use şartını bulun.

2) Disk performansının dalgalanması

Önlem: Cache katmanını doğru kurun (ör. uygulama cache + reverse proxy cache). DB yoğun işlerde disk IOPS beklentinizi testlerle doğrulayın.

3) Overselling nedeniyle yoğun saat yavaşlığı

Önlem: Testi sadece ilk saatte değil, farklı zaman dilimlerinde yapın. Mümkünse deneme süresi/iptal politikasıyla hareket edin.

4) Yedekleme (backup) belirsizliği

Önlem: Otomatik yedek varsa bile geri dönüş süresi (restore) kadar önemlidir. Restore denemesini küçük dosyalarla yapın. Yedek (backup) stratejinizi 3 katman yapın: - Uygulama yedeği - DB yedeği - Dosya/medya yedeği

5) Güncelleme ve çekirdek (kernel) kontrolü

Bazı sağlayıcılar yönetimi kısıtlar. Önlem: Kontrol panelinde (varsa) “restore/console”, kernel güncellemesi ve reboot prosedürünü kontrol edin.

6) Güvenlik güncellemeleri için zaman kaybı

Düşük maliyetli VPS’te tek kişi yöneteceği için otomasyon şart. Önlem: - Otomatik güvenlik güncellemesi - Fail2ban/benzeri brute force önlemleri - SSH anahtar zorunluluğu

7) IPv4/IPv6 ve itibar (reputation) sorunları

Mail servislerinde kritik. Önlem: Reverse DNS (PTR) ve SPF/DKIM/DMARC ayarlarının doğruluğunu kontrol edin.

8) Destek kanalının yavaşlığı

Önlem: Satın almadan önce küçük bir test ticket’i atın ve dönüş süresini gözlemleyin.

5) Kontrol paneli, lokasyon ve yedekleme: paket karşılaştırırken nelere bakılır?

Time4VPS veya BlueVPS gibi sağlayıcılarda “fiyat/özellik” kısmı kadar “operasyonel kalite” de fark yaratır.

5.1 Kontrol paneli (panel) veya erişim yöntemi

Şunları doğrulayın: - KVM/serial console erişimi var mı? - Yönetim paneli üzerinden snapshot veya benzeri var mı? - Sunucu aç-kapa/reboot işlemleri nasıl yönetiliyor?

5.2 Otomatik yedekleme ve saklama süresi

Yalnız “backup var” demeyin. Şu soruları net cevaplayın: - Yedekler günlük mü haftalık mı? - Saklama süresi kaç gün? - Yedek geri yükleme için süre ve prosedür ne?

5.3 Lokasyon seçimi ve ülke bazlı gecikme

Türkiye için: - İlgili region/POP seçeneği varsa en düşük RTT’yi hedefleyin. - Sadece ping’e değil, jitter/paket kaybına da bakın.

6) Ne zaman düşük maliyetli VPS seçilir, ne zaman seçilmez?

Net eşikleri uygulamanın gereksinimine göre belirleyin.

Uygun olduğu senaryolar

• Trafiği düşük/orta web siteleri (okuma ağırlıklı)
• Test ortamı, staging, deneme ortamları
• CI/CD runner (tam zamanlı değilse)
• Kaynak ihtiyacı ölçülü uygulamalar

Uygun olmadığı senaryolar

• 7/24 çalışan realtime servisler (oyun/iletişim)
• Kritik DB yazma yoğunluğu (yüksek IOPS isteyen sistemler)
• SLA’sı beklenen kurumsal üretim yükleri
• Gün içinde performans dalgalanmasına toleransı olmayan sistemler

Sonuç: Aksiyon planı (satın almadan önce 30-60 dakika)

Time4VPS veya BlueVPS gibi düşük maliyetli sağlayıcıları “ucuz olduğu için” değil, belirli testlerde beklentiyi karşıladığı için tercih edin. İlk adım olarak paket sayfasında CPU/RAM/disk/ağ limitlerini net okuyun; ikinci adım olarak ping + disk IOPS + kısa yük testiyle gerçeği ölçün. Son olarak yedekleme/restore prosedürünü doğrulayın ve destek hızını bir ticket ile test edin. Bu 30-60 dakikalık çalışma, ileride veri kaybı, timeout ve performans şoklarının maliyetini düşürür.

İsterseniz bir sonraki adım olarak kullandığınız uygulama türünü (WordPress mi, panel mi, API mi), hedef kitlenin konumunu (Türkiye içi mi, Avrupa mı) ve yaklaşık aylık trafiği yazın; buna göre hangi kriterlerin “must-have” olacağını NetKıyas karşılaştırma yaklaşımıyla netleştirecek bir kontrol listesi hazırlayabilirim.