Time4VPS ve BlueVPS gibi düşük maliyetli VPS’lerde net kontrol listesi

Düşük maliyetli VPS/VDS sağlayıcıları (ör. Time4VPS, BlueVPS) cazip görünür; fakat “ucuz” fiyatın arkasında kaynak paylaşımı, trafik/IO limitleri ve destek modeli gibi teknik tercihler bulunur. Bu yazıda, NetKıyas’ta karşılaştırmayı hızlandıracak şekilde düşük bütçeli sağlayıcıları net kriterlerle test edeceğiniz bir kontrol listesi paylaşacağım. Ayrıca aynı sunucu türünde (genelde KVM tabanlı VPS) hangi puanların kritik olduğunu ve nasıl ölçüm alacağınızı adım adım yazıyorum.

Düşük maliyetli VPS’te asıl risk: “paylaşılan kaynak” net anlaşılmazsa performans düşer

Uygulamada düşük maliyetli tekliflerde en sık yaşanan sorun, “CPU/RAM” etiketinin yanı sıra gerçek performansı belirleyen katmanların (hypervisor throttling, disk IOPS limiti, network shaping) açık olmamasıdır. Bu yüzden satın almadan önce ürün sayfasındaki yazılara değil, ölçüm ve doğrulamaya odaklanın.

Sağlayıcıya bakarken şu 6 veriyi şart koşun

Aşağıdaki maddeler, Time4VPS/BlueVPS gibi bütçe odaklı hizmetlerde karar vermeyi netleştirir:

1. CPU modeli ve garanti: “Guaranteed”/“Burst” ayrımı var mı? Tek çekirdek mi çok çekirdek mi? (Bursting varsa yük altında düşüş beklenir.)
2. RAM tipi: Donanım ayrımı net mi? Overcommit (aşırı tahsis) oranı belirtiliyor mu?
3. Disk türü ve IOPS: SSD/HDD değil; “IOPS değeri”, “burst IOPS” gibi net sınırlar var mı?
4. Network çıkış limiti (egress): Trafik sınırlaması, fair-use ve ücretlendirme koşulu net mi?
5. IPv4/IPv6: Tek IP mi veriliyor, ek IP ücretli mi? Reverse DNS (rDNS) sağlanıyor mu?
6. SLA ve iade şartı: Sunucu denemesini hangi süreyle yapabilirsiniz? “Kullanım hatasında iade yok” maddeleri teknik testinizi etkileyecek mi?

Bu 6 bilgi net değilse, düşük fiyatın “uygun ama belirsiz” sınıfına girdiğini kabul edin. Burada yapılacak en doğru hamle, deneme süresi varsa önce ölçüm almak ve log/performans kanıtını çıkarmaktır.

Satın almadan önce test edeceğiniz metrikler: gecikme, jitter, disk IOPS, throttling

Düşük maliyetli VPS’lerde performans şikayetleri genellikle dört başlıkta toplanır: ağ gecikmesi, gecikme dalgalanması (jitter), disk IOPS/latency ve CPU throttling. Bu başlıklardan her biri için ölçüm yöntemi belirlemek gerekir.

Ağ kalitesi için 3 ölçüm

1. ICMP ping: Sunucu lokasyonu ile hedef kullanıcı kitleniz arasında. Tek sefer değil, 5-10 dakikalık örnekleme alın.
2. TCP port latency: Gerçek uygulama trafiğine yakın test (ör. 443 üzerinden). Sadece ping değerine bakmak yanıltır.
3. Download/upload shaping etkisi: Aynı saatlerde birden fazla akışla test ederek hız düşüşü var mı kontrol edin.

NetKıyas’taki karşılaştırmalar için önerim: “lokasyon var” ifadesi yerine, hedef ülkenize göre ölçüm alın. Almanya/Polonya/Fransa gibi lokasyonlar ile Türkiye arasındaki RTT genelde yeterli olur ama jitter fark yaratabilir.

Disk için 2 ölçüm (en çok gözden kaçan kısım)

• fio ile IOPS/latency ölçümü (rastgele okuma-yazma):
• 4K r/w mix veya 8K r/w ile 30-60 saniye koşun.
• “iops düşük ama throughput yüksek” senaryosu sık görülür. Uygulamanıza göre ikisi de önemli olabilir.
• fio sonrası uygulama testi: Örneğin WordPress cache + veritabanı senaryosu. Disk yavaşsa web tarafı değil, veri katmanı patlar.

Disk IOPS limitleri düşük maliyetli VPS’lerde daha hızlı fark edilir; özellikle yoğun log yazma, küçük dosya çokluğu ve veritabanı (MySQL/PostgreSQL) işleri.

CPU throttling’i net yakalamak için 1 pratik yaklaşım

CPU throttling’i anlamanın en kısa yolu, kısa süreli ama sürekli yük kurmaktır: - 5-10 dakika CPU yükü üretin (ör. stress-ng benzeri araçlarla). - Aynı süre içinde top/htop ve sysstat metriklerini (özellikle steal time) takip edin.

Steal time yüksekse (kullanıcıların “sanki CPU var ama yavaş” demesine neden olan durum), burst/overcommit etkisi olabilir. Bu durum düşük maliyetli sağlayıcılarda daha olasıdır.

Sağlayıcı karşılaştırması nasıl yapılır? Time4VPS/BlueVPS benzeri tekliflerde tablo bazlı karar

Aşağıdaki tablo, düşük maliyetli sağlayıcıları hızlı sınıflandırmak için işlevseldir. Net karar için her satırda “hedef kullanım” ile “teknik risk” eşleştirin.

Kontrol paneli mi, ham erişim mi? (ISPManager/cPanel benzeri karar)

Düşük maliyetli sağlayıcılar bazen daha sınırlı yönetim seçenekleri sunar. Burada net ölçüt şudur: - Basit web kurulumları için yönetim paneli pratik olabilir. - Daha teknik kullanıcılar için SSH + yapılandırma izleri (config + log) daha hızlı sorun çözer.

NetKıyas’ta karşılaştırma yaparken şu soruyu kullanın: “Sorun yaşadığımda çözmek için ne kadar erişim ve log görebiliyorum?” Panel varsa bile, sistem loglarına erişemiyorsanız zaman kaybı artar.

Limitler ve “gizli maliyetler”: bant genişliği, saatlik throttling, ek IP ve yedekleme

Ucuz VPS’lerde fiyatı düşüren kalemler çoğu zaman kullanım arttıkça görünür hale gelir. Bu yüzden sadece aylık ücrete değil, kullanımın doğuracağı maliyetlere bakın.

Trafik (egress) ve bağlantı şekillendirme (shaping)

Düşük maliyetli planlarda en sık görülen senaryo: - Başta hız normal görünür. - Belirli eşiğe yaklaşınca hız kesilir veya paket kaybı artar.

Net ölçüm için 1 günlük plan kurun: - Beklenen günlük trafiğinizi hedefleyin. - Sunucuda egress kullanan servisleri (web, API, dosya indirme) aynı profilde simüle edin.

Ek IP, IPv6 ve rDNS masrafı

Eğer işiniz e-posta gönderimi, SMTP tabanlı sistemler veya yüksek itibar gerektiriyorsa rDNS kritik hale gelir. Şu kontrolü uygulayın: - Tek IP ile çalışıp çalışmadığınızı netleştirin. - rDNS veriliyorsa belgelenmiş mi, değilse zaman kaybını hesaba katın.

Yedekleme (backup) modelini “gerçekten” doğrulayın

Bazı sağlayıcılar “yedek var” der; fakat: - hangi sıklıkta, - kaç gün saklandığı, - geri dönüş süresinin (RTO) ne olduğu, - yedeğin gerçekten restore edilip edilemediği net değildir.

Net yaklaşım: - Deneme/ilk kurulum sırasında yedek alma + restore denemesi yapın. - “Aksiyon sonrası doğrulama” yapmadan sadece yedek varlığına güvenmeyin.

Düşük maliyetli VPS alırken iade sürecini ölçüm kanıtıyla yönetin

İade/iptal sürecinde satıcı tarafının “kullanım hatası” veya “harici neden” iddiasına karşı kanıt gerekebilir. Burada net strateji, satın aldıktan sonra bir test dosyası oluşturmaktır.

24 saatlik kanıt paketi (teknik olarak işe yarar)

• Test zaman çizelgesi (UTC veya sağlayıcının saat dilimi)
• ping çıktıları
• fio çıktıları
• Sunucu kaynak grafikleri (CPU steal, disk latency)
• Uygulama tarafı: ör. Nginx/Apache erişim logları ve hata logları

Bu kanıtlar sayesinde sağlayıcıyla konuşurken “ben yavaşlık yaşıyorum” demek yerine “şu metrikler şu tarihte bu aralıkta böyle” diyebilirsiniz. NetKıyas kullanıcılarının sık yaşadığı tartışmaları minimize eden şey, ölçümün tekrarlanabilir olmasıdır.

Hangi senaryoda Time4VPS/BlueVPS benzeri düşük maliyetli VPS net uygun, hangisinde değil?

Aşağıdaki sınıflandırma, kararınızı hızlandırır.

Net uygun senaryolar

• Geliştirme/staging ortamı (CI/CD testleri)
• Küçük-orta trafikli web siteleri (statik + cache ağırlıklı)
• Veri tabanı yükü sınırlı olan uygulamalar
• Erişim ve loglarla kendi yönetinizi rahatça yapabilen ekipler

Bu senaryolarda deneme süresiyle disk IOPS ve network shaping’i doğrulayıp devam edebilirsiniz.

Net riskli senaryolar

• Kritik gerçek zamanlı uygulamalar (yüksek jitter gerektiren durumlar)
• Yoğun veritabanı yazması (çok sayıda küçük işlem)
• Büyük dosya dağıtımı ve sürekli egress maliyeti doğuran işler
• E-posta trafiği yüksek ve IP/itibar kritik olan sistemler (rDNS ve IP planı net değilse)

Bu durumlarda düşük maliyetli plan, “başta idare eder” sonra maliyetli performans sorunlarına dönüşebilir.

Sonuç: Düşük maliyetli VPS seçimini tek sayı yerine 4 metrikle netleştirin

Time4VPS ve BlueVPS gibi sağlayıcıları karşılaştırırken “ucuz plan” mantığını doğru kurmak için tek bir aylık ücret üzerinden karar vermeyin. İlk adım olarak CPU throttling göstergesi, disk IOPS/latency ölçümü, network shaping etkisi ve yedek/restore doğrulamasını deneyin. Ardından aynı uygulama senaryosunu 24 saat çalıştırıp kanıt metriklerinizi çıkarın. Bu testleri tamamlamadan geçiş yapmayın; tamamladıktan sonra düşük maliyetli planlar net şekilde mantıklı hale gelir.

İlk kurulum için önerim: mevcut iş yükünüzün küçük bir kopyasıyla başlayın, 24 saat ölçüm alın ve metrikler hedeflerinizi karşılıyorsa devam edin. Karşılamıyorsa bir üst bant veya daha şeffaf limit politikasına sahip sağlayıcıya geçmek zaman kazandırır.