VPS Kaynaklarını İş Yüküne Göre Seçmek
Bir kampanya sırasında sepet güncellemeleri ve ödeme yanıtları yavaşladığında CPU, RAM veya disk sınırına ulaşılmış olabilir. Ancak dolu kaynak grafikleri, kodun ve veritabanının doğru olduğunu kanıtlamaz. VPS kaynakları seçimini istek türü, sorgu maliyeti, önbellek davranışı ve arka plan işleriyle birlikte değerlendirmek gerekir.
WooCommerce, Laravel ve Node.js tek bir kaynak profiline sahip değildir. WooCommerce’de anonim katalog ile dinamik ödeme; Laravel’de API ile rapor kuyruğu; Node.js’de kısa HTTP istekleri ile uzun WebSocket bağlantıları ayrı yükler oluşturur. Aynı teknolojiyle kurulan iki uygulamanın gereksinimleri bu yüzden farklı olabilir.
Bu rehber CPU, RAM, NVMe depolama ve ağ kapasitesini hangi ölçümlerle seçeceğinizi açıklar. Örnek senaryolar hesaplama ve test yaklaşımını göstermek içindir; belirli bir müşteri sonucu veya bütün uygulamalara uyan paket önerisi değildir.
CPU: Tek İşlem Hızı ve Paralel Kapasite
Tek çekirdek gücü ve eşzamanlılık
Standart PHP-FPM kullanımında bir işçi aynı anda bir isteği yürütür; PHP kodu çoğunlukla tek yürütme iş parçacığındadır, ancak süreç belirli bir çekirdeğe sabitlenmiş değildir. CPU ağırlıklı adımlarda çekirdek başına performans önemlidir; veritabanı veya dış API beklemesini tek başına daha hızlı CPU çözmez. Node.js ana JavaScript döngüsü tek iş parçacığında çalışırken çalışma zamanı libuv havuzu ve başka iş parçacıklarından da yararlanabilir.
WooCommerce için pratik CPU ipuçları
WooCommerce’de dinamik istek başına CPU süresini, PHP-FPM bekleme kuyruğunu ve yavaş sorguları ölçün. OPcache tekrar derleme işini azaltabilir; işçi sayısını CPU kadar RAM ve veritabanı bağlantı bütçesi de sınırlar. İncelenmiş kişisiz sayfa yanıtlarında cache kaynak işini azaltabilir: WooCommerce’de HTML cache ve bypass mantığını doğru kurgulamak. Sepet ve ödeme maliyetini ayrıca test edin.
Laravel’de kuyruk işleri ve işçi süreçleri
E-posta, görsel işleme ve raporları uygun bir asenkron kuyruğa taşımak isteğin beklediği işi azaltır; toplam CPU tüketimini kendiliğinden azaltmaz. sync sürücüsü işi arka plana taşımaz. Web ve kuyruk süreçlerine ölçülmüş bütçe ayırın. Laravel 11.x Horizon belgesi o sürüme özgüdür; 13.x belgesi dahil kurulu sürümünüzün referansını kullanın. Horizon yalnız Redis kuyrukları içindir.
Node.js’de olay döngüsü ve ölçek
Tek Node.js süreci asenkron I/O ile çok sayıda bağlantıyı eşzamanlı yönetebilir. Ana döngüyü yoran JavaScript hesaplarını bölmek veya sınırlı bir worker_threads havuzuna taşımak gerekebilir. Cluster işçi süreçleri ya da ters proxy arkasında ayrı süreçler bağlantıları dağıtabilir; süreç sayısını körlemesine vCPU sayısına eşitlemeyin. CPU kotası, bellek ve ortak veritabanı da sınırdır.
RAM: Yastık Gibi, Dar Gelirse Uykun Kaçar
PHP, Node ve veritabanı aynı yastığa sığar mı?
WooCommerce ve PHP tabanlı Laravel kurulumlarında işçi süreçleri, OPcache, veritabanı ve varsa Redis aynı RAM bütçesini paylaşır. Kuyruk işçilerini ve eşzamanlı yönetim görevlerini de sayın. Node.js’de bağlantı durumları, yanıt tamponları ve büyük payload’lar bellek tüketir. Kullanılabilir RAM, etkin swap giriş/çıkışı ve OOM kayıtları birlikte izlenmelidir; dolu dosya cache’i tek başına yetersiz RAM demek değildir.
Önbellekler RAM’i neden hak ediyor?
Cache ancak tekrar kullanılan doğru veriyi saklıyorsa yararlıdır. WooCommerce nesne cache’i, oturum deposunu otomatik olarak Redis’e taşımaz. Laravel rota/konfigürasyon cache’ini sürüm ve uygulama uyumluluğuna göre kurun. OPcache için kod kümesine uygun pay ayırın; geliştirmede de kullanılabilir, fakat değişiklik algılama ayarları geliştirme akışına uymalıdır. Üretimde güncelleme sırasında geçersizleştirme politikasını doğrulayın.
RAM tıkanıklığının sessiz işaretleri
Düşük CPU ile yüksek gecikme yalnız bellek sorununu göstermez: veritabanı kilitleri, disk, ağ ve dış servis beklemeleri de neden olabilir. PHP işçilerinin yoğun yükteki özel bellek/PSS dağılımını ölçün; toplam RSS ortak OPcache alanını tekrar sayabilir. İşçi sayısını azaltmak bellek baskısını hafifletirken kuyruğu uzatabilir. Sunucu tarafı optimizasyon rehberi ayarları birlikte ele alır; değişiklik sonrası gecikmeyi yeniden ölçün.
NVMe Depolama: Hızın Sessiz Kahramanı
IOPS ve gecikme neden sonuçları değiştirir?
Disk için kapasite kadar I/O gecikmesi, IOPS, aktarım hızı ve kalıcı yazma davranışı önemlidir. SQL sorgusu sayısı disk IOPS değeriyle aynı değildir; cache ve toplu yazma sonucu değiştirir. NVMe iyi bir seçenek olabilir ama VPS kotası, ortak depolama yükü ve blok boyutu gerçek sonucu belirler. Yalnız NVMe etiketine bakarak gecikme veya veritabanı kilidi sorununun çözüleceğini varsaymayın.
Gözden kaçan detaylar: loglar, yedekler, tmp
Log, geçici dosya ve yedeklerin büyümesini; boş alanı ve inode kullanımını izleyin. Log döndürme/saklama planı yapın ve ağır işleri yoğun saatlerle çakıştırmayın. Aynı diskteki yedek yerel kopya olabilir, fakat disk veya sunucu kaybına karşı tek koruma olamaz. 3‑2‑1 yedekleme stratejisi ile bağımsız kopyaları ve ölçülmüş geri yükleme testlerini planlayın.
Veritabanı yerleşimi ve küçük sihirler
MySQL/MariaDB veri ve günlük dosyalarının depolama gecikmesini iş yükü altında ölçün. Redis esas olarak RAM’den çalışır; “Redis’i NVMe’ye koymak” her okumayı hızlandıran bir mekanizma değildir. Disk, AOF/RDB kalıcılığı ve yeniden başlatma sırasında önem taşır. Kuyruk veya oturum verisinin kaybını, yeniden üretilebilir cache verisinin atılmasıyla aynı kabul etmeyin; kalıcılık ve eviction politikasını ayrı tasarlayın.
Bant Genişliği ve Ağ: Kalabalık Anlarda Nefes Nasıl Korunur?
Aylık Veri Kotası ve Anlık Aktarım Hızı
Aylık GB/TB kotası ile anlık Mbps kapasitesini ayrı değerlendirin. Örnek bir hesapta kaynaktan saniyede 100 yanıt × aktarılmış yanıt başına 50.000 bayt × 8 / 1.000.000 yaklaşık 40 Mbps gövde trafiğidir; protokol yükü ve dalgalanma payı eklenmelidir. CDN cache kaçırmaları, upload’lar ve WebSocket mesajlarının çok sayıda alıcıya dağıtımı da hesaba girer. Veri merkezinin kullanıcıya ağ gecikmesini ve sağlayıcının kota aşımı politikasını kontrol edin.
CDN, önbellek ve edge sihri
CDN, incelenmiş herkese açık statik dosyaları ve gerçekten kişisiz HTML’i kaynaktan alabilir. Giriş yapmamış ziyaretçinin de sepeti veya özel fiyatı olabilir. Gerçek sepet/ödeme/hesap yolları, eylem parametreleri, oturum cookie’leri, Authorization ve kişisel Store API yanıtlarını bypass edin; ilk Set-Cookie yanıtını da koruyun. WooCommerce CDN önbellek kuralları ayrıntıları açıklar. Nesne depolama tek başına CDN değildir; görsel boyutunu ve formatını ayrıca iyileştirin.
Bağlantı yönetimi ve sınırlar
Zaman aşımı ve geri çekilmeli tekrar deneme yararlıdır, fakat tek başına kuyruk büyümesini sınırlamaz. Bağlantı havuzlarına, bekleyen işlere ve mesaj tamponlarına açık sınır koyun; backpressure ve uygun rate limit kullanın. Tekrar denemelere jitter, üst sınır ve yinelenen işlemi önleyen idempotency ekleyin. Webhook sınırlarını sağlayıcının yeniden deneme davranışına göre test edin. Ödeme akışındaki dış servis gecikmesini yerel kaynak yetersizliğinden ayırın.
Örnek İş Yükleri
WooCommerce: Butik mağazadan kampanya haftasına
Örnek bir mağazada anonim ürün sayfaları ile sepet, ödeme, yönetim ve stok senkronizasyonunu ayrı test edin. Cache ısıtma yardımcı olabilir, ancak soğuk cache ve purge sonrasındaki yük de kapasiteye dahil olmalıdır. Yalnız kişisiz HTML’i paylaşın; iki ayrı müşteri oturumunda veri karışmadığını doğrulayın. Trafik miktarı kadar dinamik istek oranı ve istek maliyeti önemlidir: WooCommerce kapasite planlama rehberi hesabı derinleştirir.
Laravel: Kuyruklar, planlı işler ve API dayanıklılığı
Örnek bir Laravel uygulamasında web ve kuyruk süreçlerinin kaynak sınırlarını ayırın. İş sayısının yanında en eski işin yaşı, iş süresi, başarısızlıklar ve tamamlanma hızını izleyin. Redis kuyruklarında Horizon kullanılabilir. Daha fazla işçi veritabanını veya dış API’yi aşırı yükleyebilir; yalnız ölçümler destekliyorsa artırın. timeout, retry_after kullanan bağlantılarda ondan kısa olmalıdır; SQS gibi sistemlerde görünürlük süresi ayrıca ele alınır. İşçiler dağıtımda yeniden başlatılmalı; bellek birikiminin nedeni araştırılmalıdır.
Node.js: Gerçek zamanın sinsi sürprizleri
Node.js’de bağlantı sayısıyla sınırlı bellek artışı beklenebilir; yük sabitken sürekli büyüme normal kabul edilmemelidir. Heap, RSS, dış tamponlar, GC ve olay döngüsü gecikmesini birlikte inceleyin; kapalı bağlantıların listener/timer ve durum verilerini temizleyin. Çok süreçli WebSocket tasarımı ortak durum/pub-sub, uygun bağlantı yönlendirmesi ve kontrollü boşaltma gerektirir. Yeni süreç açılması mevcut bağlantıları otomatik taşımaz.
Ölçekleme, İzleme ve Bakım: Yolda Kalmamanın Sırları
Ölçmeden bilemezsin
CPU/kota sınırı, PHP kuyruğu, kullanılabilir RAM, disk gecikmesi, ağ aktarımı, p95/p99 yanıt süreleri ve hata oranını birlikte izleyin. Yük testlerini yalıtılmış verilerle; test ödeme/e-posta uçlarıyla yürütün ve kuyrukların boşalma süresini ölçün. Taşıma için TTL stratejileri geçiş planını destekler; TTL düşürmek mevcut cache’i anında boşaltmaz veya tek başına kesintisiz geçiş sağlamaz. Veri eşitleme ve eski hedefin çalışma süresi de planlanmalıdır.
Dikey mi yatay mı? Önce nefes aç
Dikey büyütme ölçülmüş CPU veya RAM sınırını giderebilir; yeniden başlatma gereksinimini sağlayıcıyla doğrulayın. Laravel kuyruklarını ayrı bir VPS üzerinde çalıştırmak ya da Node.js bağlantı katmanını ayırmak kaynak paylaşımını değiştirebilir. Yatay ölçekleme ortak veritabanı, oturum ve iş sahipliği sorunlarını çözmeyi gerektirir. Her adımda maliyet, hata oranı ve gerçek throughput kazanımını karşılaştırın.
Güvenlik ve güncellemeler performansın kardeşidir
Desteklenen yazılım sürümleri, düzenli yamalar, en az yetki ve gereksiz servislerin kapatılması işletim kalitesinin parçasıdır; bunlar belirli bir hız artışı garantisi değildir. Güncellemeleri ve geri dönüş yolunu test edin. VPS sunucu güvenliği rehberi erişim ve bakım kontrollerini tamamlar.
Kaynak Seçimini Ölçümle Doğrulayın
CPU’yu işlem süresi ve paralel iş miktarına; RAM’i süreçler, cache ve tepe kullanıma; diski gerçek gecikme/kotalara; ağı hem anlık aktarım hem aylık toplamına göre seçin. Evrensel bir vCPU veya RAM sayısı yoktur. Başlangıç kapasitesine ölçülmüş büyüme payı ekleyin ve hangi eşikte hangi değişikliği yapacağınızı önceden belirleyin.
Darboğazı saptayın, bir değişiklik yapın ve aynı yük deseniyle sonucu yeniden ölçün. WooCommerce’in resmî sunucu gereksinimleri uyumluluk için başlangıçtır; mağaza kapasitesi kıyaslaması değildir. Laravel’de kullanılan sürümün kuyruk belgesini, Node.js’de olay döngüsü ve bellek ölçümlerini uygulamanın gerçek davranışıyla birlikte değerlendirin.
