Magento 2 hosting: Ciddi spec şart mı? Net rehber

Magento 2, sıradan bir içerik yönetim sistemine (CMS) göre daha fazla işlem yapar: her istek; PHP tarafında sayfa oluşturma, veri çekme (MySQL), yoğun cache kullanımı ve statik içeriğin yönetimi gibi adımları beraber yürütür. Bu yüzden “yüksek spec şart mı?” sorusu çoğu ekip için bütçe ile performans arasında doğrudan bir karardır.

Bu rehberde, Magento 2 için donanımı büyütmeden önce hangi metrikleri kontrol etmeniz gerektiğini; hangi durumlarda “ciddi spec” talebinin gerçekten haklı çıktığını; hangi durumlarda ise doğru mimariyle (cache, FPC, opcache, doğru MySQL ayarları) daha düşük spec ile ilerleyebileceğinizi net şekilde anlatıyorum. Son bölümde de pratik bir kontrol listesi ve doğru plan türünü seçmeniz için aksiyon önerisi var.

Magento 2 hangi yükleri üretir? (Spec nerede işe yarar?)

Magento 2’nin kaynak kullanımı istek türüne göre değişir. Tek bir “minimum ram/CPU yeter” cevabı yoktur; asıl belirleyiciler şunlardır:

PHP uygulama katmanı: Sizin kodunuz (tema, eklentiler) + Magento çekirdek işlemleri CPU/RAM kullanır.
Veritabanı (MySQL): Kötü index, yanlış sorgu, yetersiz bağlantı yönetimi ve yüksek eşzamanlılık “too many connections” gibi hatalara yol açar.
Cache katmanı: Magento 2’nin sayfa oluşturma adımlarını azaltan mekanizmalar (full page cache ve veri cache) kritik rol oynar.
Statik dosyalar: CSS/JS/IMG üretimi veya teslimi bant genişliği ve depolama I/O ile ilişkilidir.
Sürekli trafik vs tepe trafik: Bayram kampanyası gibi dönemlerde eşzamanlılık (concurrency) artar ve “küçük spec” sınırı hızla görünür olur.

Bu yükleri doğru yere oturtursanız, donanım yükseltme ihtiyacını geciktirebilirsiniz. Aksi halde yüksek spec bile tek başına sorunu çözmeyebilir.

“Ciddi spec” hangi senaryolarda gerçekçi gerekir?

Aşağıdaki durumlarda spesifik olarak CPU/RAM/IO ve ölçeklenebilirlik ihtiyacı belirginleşir:

Trafik tepe noktaları sık ve yüksek (gün içinde sürekli yüksek sipariş/ürün görüntülenme): CPU ve MySQL eşzamanlılığı artar.
Çok sayıda eklenti (extension) ve özelleştirme: Her istek başına ek sorgu/işlem eklenir.
FPC (full page cache) düzgün çalışmıyor: Cache kaçırma olduğunda her istek ağırlaşır.
MySQL index/şema optimizasyonu yapılmadı: Yük arttıkça yavaş sorgular büyür.
Yüksek eşzamanlı checkout/arama: Uygulama katmanı + DB katmanı beraber zorlanır.

Magento 2’de “spec” tek başına yeter mi? Hayır: mimari şart

Magento 2 için doğru spec, doğru mimari olmadan maliyete dönüşür. En sık fark yaratan bileşenler:

Cache sistemi ve doğru cache stratejisi
PHP opcache ayarı
Redis / Varnish / FPC konfigürasyonu
MySQL bağlantı ve sorgu performansı
Statik içerik yönetimi (CDN + doğru deploy pipeline)

Bu başlıklar, aynı VDS/VPS planında bile 5-10 kat performans farkı yaratabilir. Özellikle FPC devre dışı kaldığında “RAM’i artırdım” yaklaşımı genelde geciktirici olur, kalıcı çözüm olmaz.

Minimum gereksinim yerine: hedef metriğe göre karar verin

“Ne kadar RAM/CPU gerekir?” sorusunu şu şekilde netleştirin: Magento 2’nin performansı için pratik hedef metrikler belirleyin.

Aşağıdaki hedefler, hosting seçerken karar vermeyi kolaylaştırır:

TTFB (Time to First Byte) hedefi: İlk yanıt süresi. (Kıyas için aynı rota/kategori sayfası ve aynı örnek veri seti.)
Kritik sayfalar için P95 yanıt süresi: Tek bir ölçüm değil, varyans.
MySQL bağlantı sayısı: tepe anlarda bağlantı patlaması olmamalı.
CPU steal ve load: Paylaşımlı ortamlar veya oversell durumlarında performans oynar.
Cache hit oranları: FPC hit düşükse uygulama katmanı şişer.

Pratik test: Cache doğru mu çalışıyor?

Yapılacak en değerli iki kontrol:

Sayfa ilk açılışında hızlı mı, sonrasında hızlanıyor mu?
Yönetim panelinden değişiklik yapınca cache temizliği sonrası tekrar oturuyor mu?

Bu kontroller, “yüksek spec” almadan önce mimari sorun olup olmadığını gösterir.

Hosting türü seçimi: paylaşımlıdan VDS/VPS/Dedicated’a geçiş mantığı

Magento 2 için en sık yapılan hata: “paylaşımlı hosting bile çalışır” diyerek yanlış ortamı kabul etmek. Magento 2’nin yoğun istek profili, kaynak sınırları ve proses paylaşımı nedeniyle stabilite riski oluşturur.

Magento 2’de pratik yaklaşım:

Yeni başlıyorsanız: Öncelik cache + MySQL optimizasyonu + sağlam PHP runtime ile kontrollü büyüme olmalı.
Büyüdüyseniz: Statik teslim (CDN) + uygulama (VDS/VPS) + gerekirse DB’yi ölçekleme (ayrı plan) daha net sonuç verir.

Aşağıdaki tablo “ne zaman ciddi spec gerekir?” sorusunu tür seviyesinde yanıtlar.

Magento 2 kullanım durumu	Dikkat edilmesi gereken darboğaz	Önerilen hosting yaklaşımı
Az trafik + temel theme + sınırlı extension	Cache hit oranı ve PHP performansı	İyi yapılandırılmış VDS/VPS; Redis + FPC konfigürasyonu
Orta trafik + düzenli ürün/kategori güncellemesi	MySQL sorgu süresi + eşzamanlılık	Ayrı kaynaklı VDS/VPS; MySQL tuning + doğru indeksler
Yüksek trafik + kampanya dönemleri	CPU tepe + DB bağlantı yönetimi	Ölçeklenebilir mimari; gerekirse dedicated veya DB ayrımı
Çok extension + kompleks checkout/arama	Uygulama katmanı ve sorgu yükü	Daha güçlü CPU/RAM + düzenli profiling/optimization
7/24 yüksek availability ihtiyacı	Kesintisiz servis ve hızlı failover	Stabile altyapı + yedekleme (backup) stratejisi

“Ciddi spec” için somut kontrol listesi (satın almadan önce)

Hosting sağlayıcıyla görüşürken aşağıdaki maddeleri netleştirin. Bunlar, donanım kadar önemlidir.

1) PHP çalışma zamanı ve sınırlar

Magento 2 için PHP’nin sürümü kadar şu limitler de kritik:

memory_limit
max_execution_time
opcache (opcode cache) aktif mi?
PHP-FPM yapılandırması: worker sayısı ve process davranışı

Bu limitler düşükse, performans değil “stabilite” sorunu yaşarsınız.

2) Redis ve cache katmanı desteği

Magento 2’de Redis kullanımı pratikte çok yaygındır. Sağlayıcı şu sorulara net cevap vermelidir:

Redis ayrı süreç/ayrı kaynak olarak mı veriliyor?
En azından bağlantı/latency için ölçülebilir durum var mı?
Cache temizliği (flush) nasıl yönetiliyor?

3) MySQL erişimi: bağlantı ve performans

MySQL tarafında iki konu belirleyici:

Bağlantı (connections) yönetimi: eşzamanlılık artınca bağlantı patlaması olmamalı.
Disk I/O ve query performansı: SSD kullanımı ve DB ayarları.

Sağlayıcıdan “SSD var” dışında şu bilgileri isteyin:

En yüksek eşzamanlı yükte DB performansı nasıl davranıyor?
Gerekirse MySQL ayarlarına erişim var mı (custom tuning)?

4) Depolama (SSD/NVMe) ve I/O gecikmesi

Magento 2’de hem deploy süreci hem de cache/varlık üretimi depolama ile ilişkilidir. “Ciddi spec” ihtiyacının arkasında bazen CPU değil disk I/O çıkar.

Kontrol:

SSD mi NVMe mi?
Disk throttling var mı?
Eş zamanlı okuma/yazma yükünde performans dalgalanması oluyor mu?

5) Yedekleme (backup) ve geri dönüş hedefi

Magento için “yedek var” demek yetmez. Ne kadar hızlı geri dönebileceğiniz kritik olur.

Net sorular:

Full backup + incremental (artımlı) var mı?
Geri dönüş süresi (RTO) hedefiniz nedir?
Snapshot (anlık görüntü) kullanılıyorsa bu gerçek backup stratejisi mi, yoksa sadece anlık durum mu?

Cache + optimizasyonla spec ihtiyacını nasıl azaltırsınız?

Aşağıdaki önlemler çoğu Magento 2 kurulumunda “donanım yükseltme” ihtiyacını geciktirir.

1) FPC’yi doğru çalıştırın

FPC düzgün çalışmazsa her istek ağır olur. Bu durumda yüksek CPU/RAM almak, sorunu maskelemeye dönüşür.

Hangi sayfalar cache’leniyor?
Özel bloklar (ör. müşteriye özel içerik) cache kaçırıyor mu?
Arama/filtre gibi sayfalarda cache stratejisi net mi?

2) OpCache’i aktif ve doğru ayarlayın

PHP dosyalarının opcode olarak önbelleğe alınması, her istekte derleme maliyetini azaltır.

3) MySQL sorgularını “tek tek” düzeltin

Her yükte hızlanmak için en etkili yaklaşım, yavaş sorguları tespit edip düzeltmektir.

yavaş query log kullanın
kritik tablolar için index kontrol edin
yüksek trafiğe çıkan rota üzerinde sorgu sayısını azaltın

4) Statik içerik için CDN kullanın

CDN, özellikle görsel ve statik dosyalarda hosting üzerindeki bant genişliği baskısını azaltır. Bu, uygulama katmanının daha az zorlanmasına dolaylı olarak katkı verir.

Sonuç: “Ciddi spec” şart mı? Doğru cevap: Darboğaza göre

Magento 2 hosting’te ciddi spec çoğu senaryoda tek başına “mecburi” değildir; doğru cache (özellikle FPC), opcache, MySQL sorgu/index optimizasyonu ve sağlam yedekleme stratejisi varsa ihtiyaç belirgin şekilde düşer. Ancak tepe trafik, çok extension, cache kaçırma veya DB bağlantı/pattern sorunları varsa ciddi spec talebi bir lüks değil, stabilite gereksinimine dönüşür.

Aksiyon önerisi: Satın almadan önce en az 1-2 kritik senaryoyu hedefleyin (kategori sayfası, ürün sayfası, arama sonuçları, checkout öncesi adım) ve şu sırayla ilerleyin: cache hit doğrulaması → PHP limit/opcache doğrulaması → MySQL bağlantı ve yavaş sorgu kontrolü → ardından ölçüm sonuçlarına göre VDS/VPS veya dedicated kararını verin. Bu yaklaşım, gereksiz donanım maliyetini keser ve performans hedefinizi net metriklere bağlar.