Reseller’dan Dedicated’a Geçiş Ne Zaman Yapılır? Net Eşikler

Reseller (bayi) hosting kullanırken hedef genelde “büyürken maliyeti kontrol etmek” olur. Ancak belirli bir noktadan sonra performans darboğazı, kaynak paylaşımı ve kontrol paneli limitleri nedeniyle büyümek zorlaşır. Dedicated sunucuya geçiş zamanı; sadece “daha hızlı olsun” beklentisi değil, ölçülebilir sistem sinyallerine bağlı olmalıdır. Bu rehberde reseller’dan dedicated’a ne zaman geçileceğini, hangi metriklerle karar vereceğinizi ve geçiş planını net bir kontrol listesiyle anlatıyorum.

Reseller ile dedicated arasındaki farklar (karar etkileyen noktalar)

Reseller hosting genellikle paylaşımlı veya yarı izole (container/VPS benzeri) mantıkla çalışır; CPU/RAM disk I/O ve bazen süreç sayısı gibi kaynaklar aynı altyapı üzerinde birden fazla müşteriye bölünür. Dedicated sunucuda ise fiziksel sunucu tek kiracıdır. Bu fark, aşağıdaki alanlarda doğrudan hissedilir.

1) Kaynak garantisi: CPU/RAM ve süreç sınırı

• Reseller’da “kaynak paylaşımı” vardır. Tepe trafik veya yoğun cron işleri diğer siteleri etkileyebilir.
• Dedicated’da CPU/RAM tahsisi tek kullanıcıdadır; sınırlar genellikle sunucu planına göre sabitlenir.

Geçiş sinyali: Web sitesi bir büyüme yakaladığı halde, yoğun saatlerde sayfa yanıt süresi ve hata oranı artıyor; aynı zamanda başka sitelerden gelen yük de sizi etkiliyor.

2) Disk I/O ve veritabanı (DB) gecikmesi

Reseller altyapısında disk I/O sıklıkla paylaşımlıdır. Özellikle MySQL/MariaDB, yoğun sorgu, index taraması ve büyük veri tabanı tablolarında I/O bekleme süresi belirleyici hale gelir.

Geçiş sinyali: - DB sorgularında “lock wait”, “query cache miss” benzeri durumlar sıklaşır. - Aynı optimizasyonları yaptıktan sonra bile performans sabitlenmiyor ve sistem disk gecikmesi devam ediyor.

3) Güvenlik ve erişim derinliği

Dedicated’da kök yetkileri, firewall (iptables/nftables), kernel seviyesinde ayarlar ve daha kapsamlı izleme yapmak daha mümkündür. Reseller’da ise bu seçenekler kontrol paneli ve sunucu politikalarıyla sınırlanır.

Geçiş sinyali: WAF/DDoS ayarları, rate limit, özel firewall kuralı, fail2ban yapılandırması veya özel log analizi gibi konularda sağlayıcı sınırları belirginleşiyor.

4) Ağ (network) ve bant genişliği davranışı

Aynı altyapıda çoklu kullanıcı nedeniyle network kuyrukları ve bant genişliği paylaşımı görülebilir. Dedicated’da bant genişliği genellikle plan bazındadır ve daha öngörülebilirdir.

Geçiş sinyali: CDN kullanmanıza rağmen origin (sunucu) gecikmesi artıyor; özellikle video/indirilebilir içeriklerde throughput dalgalanması yaşanıyor.

Ne zaman geçilmeli? Ölçülebilir 7 eşik

Aşağıdaki eşikler “tek bir kez oldu bitti” değil, trend olarak düşünülmelidir. Aynı metriğin 2-4 hafta boyunca tekrarlı şekilde kötüleşmesi geçiş için güçlü sinyaldir.

Eşik 1: CPU kullanımında kalıcı doygunluk

• Reseller’da CPU doygunluğu çoğu zaman “sürekli yüksek load average” veya kontrol panelinde süreç limitine yaklaşma şeklinde görünür.
• Dedicated’da CPU daha öngörülebilir olsa da ilk iş doğru çekirdek planını seçmektir.

Net kural: Ortalama CPU kullanımı %70+ ve tepe değerler %90+ seviyesine 2-4 hafta içinde sık ulaşıyorsa dedicated değerlendirin.

Eşik 2: RAM yetersizliği ve swap kullanımı

Swap (sayfalama) devreye giriyorsa uygulamalar yavaşlar.

Net kural: Swap kullanımı düzenli hale geldiyse (örn. hafta içinde birden fazla kez) ve uygulama/DB performansı etkileniyorsa geçiş zamanı yakındır.

Eşik 3: Disk I/O bekleme ve DB gecikmesi

DB tarafında şunlar görünüyorsa geçiş mantıklıdır: - yavaş sorgu sayısı artıyor - buffer pool hit oranları düşüyor - disk wait time artıyor

Net kural: Optimizasyon (index, sorgu iyileştirme) sonrası da gecikme belirgin azalmıyorsa altyapı I/O paylaşımı problem olabilir.

Eşik 4: Kaynak sınırları (process limit, cron, worker)

Reseller’da cron job sayısı, PHP worker sayısı, işlem süre limitleri gibi kısıtlar performansı kilitleyebilir.

Net kural: Uygulamanın gereksinimleri büyüdüğü halde kontrol paneli limitleri yüzünden daha yüksek worker veya eşzamanlı iş çalıştıramıyorsanız dedicated’a geçin.

Eşik 5: Hata oranı ve performans SLA’sı düşüşü

Örnek sinyaller: - HTTP 5xx artışı - “timeout” hataları - belirli kullanıcı gruplarında yavaş açılma

Net kural: 2-4 haftalık trendde LCP/TTFB (kullanıyorsanız) veya hata oranı düzenli yükseliyorsa ve kök nedeniniz altyapı paylaşımıysa geçiş planlayın.

Eşik 6: Güvenlik talepleri genişledi

• Daha agresif rate limit
• özel firewall kuralları
• daha detaylı log saklama
• saldırı tespit/engelleme süreçleri

Net kural: Sağlayıcının sunduğu korumalar yetersiz kaldıysa ve güvenlik politikasını uygulamak için sunucu erişimi gerekiyor ise dedicated daha doğru olur.

Eşik 7: Maliyet artık “daha pahalı değil” mantığına dönüyor

Reseller’da bazen ek kaynak talebiyle fiyatlar artar; fakat dedicated’da tek seferde daha öngörülebilir kapasite alınır.

Net kural (maliyet testi): - Reseller maliyeti + limitleri aşınca alınan ek paketler - Dedicated’da öngörülen donanım + yönetim/kurulum maliyeti karşılaştırmasında dedicated 1-2 ay içinde daha mantıklı hale geliyorsa geçişi hızlandırın.

Reseller’dan dedicated’a geçerken doğru donanım seçimi (net kriterler)

Dedicated sunucuyu satın almadan önce, hedef uygulama profilinizi netleştirin. Aşağıdaki tablo, tipik yük profiline göre başlangıç kapasitesi önerisi sunar.

Not: “vCPU” kıyasını kullandığım için özel donanım modeline göre değişkenlik olur. NetKıyas’ta fiyat/performans karşılaştırması yaparken aynı kuşak CPU/RAM oranlarına odaklanın.

Verileri toplayın: Geçiş kararını somutlaştıran 10 metrik

Dedicated’a geçmek için en iyi argüman tahmin değil, ölçümdür. Reseller üzerinde erişebildiğiniz raporlara ek olarak, loglarınızı ve metriklerinizi toplamak için şu alanlara bakın.

Performans ve kapasite

• Ortalama ve tepe CPU kullanımı (örn. 1 dk / 5 dk)
• Ortalama RAM kullanımı + swap var mı
• Load average trendi
• Disk I/O bekleme (read/write latency)

Uygulama ve DB

• Ortalama sayfa yanıt süresi
• DB sorgu süresi p95/p99 (varsa)
• Slow query sayısı
• Lock wait sayısı / süre

Trafik ve ağ

• Günlük istek sayısı
• Band genişliği günlük trend
• HTTP hata oranı (4xx/5xx) ve timeout sayısı

Bu metrikleri 2-4 hafta boyunca aynı şekilde izlediğinizde geçiş için “iş ihtiyacı” netleşir.

Geçiş planı: Riskleri azaltan adım adım kontrol listesi

Dedicated’a geçişte en sık sorunlar; veri kaybı, DNS kesintisi ve performans düşüşüdür. Bu yüzden planı belirli sıraya oturtun.

1) Taşıma stratejisi (kesintisiz hedefleyin)

• Önce staging (test ortamı) oluşturun.
• Uygulamanın config dosyalarını ve ortam değişkenlerini çıkarın.
• DB dump (veritabanı yedeği) alın, ardından incremental yaklaşım planlayın.

2) Yedekleme ve geri dönüş (rollback)

• Geçiş öncesi son tam yedek alın.
• DB ve dosyalar için en az iki kopya planlayın.
• DNS değişimi sırasında kısa süreli rollback senaryonuzu yazın.

3) Sunucu tarafı kurulum

Dedicated sunucuda genelde şu bileşenler belirlenmelidir: - Web server (Nginx/Apache) - Uygulama PHP-FPM ayarları - DB sürümü ve storage (NVMe) - Cache katmanı (örn. OPcache, Redis) - Log rotasyon (logrotate) ve disk taşmasını önleme

4) Güvenlik katmanı

• Firewall kuralları (gerekli portlar dışında kapalı)
• Fail2ban veya benzeri brute-force koruması
• Güncel paketler ve otomatik güvenlik güncelleme politikası

5) Performans doğrulama (geçişten önce)

• Aynı senaryolarda benchmark yapın (ana sayfa, ürün/checkout, kritik API uç noktaları)
• p95/p99 gecikmeleri karşılaştırın
• DB performansını sorgu bazında doğrulayın

Dedicated’a geçişten sonra asıl kazanç: Aynı bütçeyle daha öngörülebilir sistem

Dedicated’ın “tek hamlede hızlandırma” vaadi sınırlı; gerçek kazanç, kaynak paylaşımı belirsizliğinin azalmasıdır. Sonuç olarak: - pik saatlerde zaman aşımı daha düşer - DB gecikmesi trendi stabil hale gelir - güvenlik ve izleme politikalarını istediğiniz gibi uygulayabilirsiniz

Bunu doğru yapmak için geçişin hemen ardından 1-2 hafta “gözlem + ayar” döngüsü kurun. Özellikle PHP worker sayısı, cache ayarları, DB buffer ve bağlantı limitleri gibi parametreler net kazancı belirler.

Sonuç: Geçişi bugün planlamak için net aksiyon

Reseller’dan dedicated’a geçiş zamanını belirleyen ana kriter; CPU/RAM doygunluğu, disk I/O ve DB gecikmesi, süreç limitleri ve güvenlik/erişim ihtiyaçlarının aynı anda “trend” haline gelmesidir. Bu yazıyı temel alarak bugün şu üç işi yapın: (1) son 2-4 haftanın CPU/RAM/DB ve hata trendini çıkarın, (2) yetersiz kalan alanı belirleyin (özellikle DB ve I/O), (3) staging + yedek + rollback içeren bir taşıma planı yazın. Bu üç adımı tamamladığınızda dedicated’a geçiş kararı netleşir ve geçiş sonrası sürprizler azalır.