Magento 2 Hosting’de ciddi spec şart mı? Net karar rehberi

Magento 2, basit bir blog altyapısı gibi “tek boyut” kaynakla çalışmaz. Sistem yoğunluğu; tema/eklenti sayısı, trafik deseni, cache stratejisi (tam sayfa cache, Varnish/Redis) ve veritabanı tasarımına göre ciddi şekilde değişir. Bu yazıda "ciddi spec gerekiyor mu?" sorusunu, somut kriterlerle ve kontrol listesiyle yanıtlayacağız. Böylece gereksiz pahalı paketlere yönelmeden, performansı hedefe kilitleyeceksiniz.

Magento 2’de “spec” neden tek başına yeterli değil?

Magento 2 performansı çoğu zaman tek bir donanım bileşeninden değil, kaynakların nasıl kullanılabildiğinden etkilenir. Örneğin yüksek RAM almak tek başına yeterli olmaz; aynı zamanda PHP tarafında doğru process sayısı, veritabanında doğru bağlantı/indeks yönetimi ve cache katmanlarının doğru çalışması gerekir.

Magento 2’nin tipik kaynak tüketimlerini şu şekilde ayırabilirsiniz: - CPU (işlemci): PHP-FPM worker sayısı, arka plan işleri (cron), indeksleme, yoğun eklenti/observer trafiği. - RAM (bellek): PHP süreçleri, Redis/Memcached cache kullanımı, tarama/arama işlemlerinin çalışma seti. - Disk/IOPS: Veritabanı (MySQL/MariaDB) yazma yoğunluğu, log/temporary dosyalar, cache dosyaları (file cache) ve indexlerin güncellenmesi. - Network: CDN + compress + keep-alive + (varsa) HTTP/2/3 etkisi.

Sonuç: Magento 2’de spec talebi vardır; ancak “hangi spec ve hangi ayarlarla” sorusu asıl belirleyicidir.

Magento 2 hangi senaryolarda specleri zorlar?

Magento 2 şu durumlarda kaynak ihtiyacını hızla artırır: - Çok sayıda ürün/kategori + yoğun listeleme/filtreleme - Çok eklentili tema (özellikle kategori/ürün sayfasında ek çağrılar yapanlar) - Hızlı ve sık değişen stok/sınıf fiyatları (reindex ve cron yükü) - Yönetim panelinde yoğun operasyonlar (ürün/ürün özellikleri düzenleme) - Arama/indeksleme süreçlerinin düzgün zamanlanmaması

“Ciddi spec” ihtiyacını 4 ölçü ile net hesaplayın

Aşağıdaki 4 ölçü, kaç vCPU ve kaç GB RAM’e ihtiyacınız olduğunu tahmin etmenin en pratik yoludur. Bunları mevcut bir Magento ortamınız varsa ölçün; yoksa hedef trafiğe göre proje tablosu oluşturun.

1) Trafik ve eş zamanlı istek (concurrency)

Hedef eş zamanlı istek, PHP worker ihtiyacını doğrudan etkiler. - Ortalama kullanıcı sayısı (gün içi) - Tepe saat eş zamanlı kullanıcı (ör. kampanya anı) - Sayfa başına ortalama istek sayısı (özellikle JS/CSS/CDN durumuna göre)

Pratik kural: Kampanya günlerinde eş zamanlılık artıyorsa, yalnızca ortalama trafikten değil “tepe saat”ten hareket edin.

2) Ürün/kategori ölçeği ve listeleme karmaşıklığı

Ürün sayısı (ör. 10k / 50k / 200k)
Kategori sayısı ve katman derinliği
Fiyat/filtre (layered navigation) kullanım sıklığı

Bu ölçek büyüdükçe veritabanı sorgu maliyeti artar; dolayısıyla RAM + IO tarafı önem kazanır.

3) Eklenti/tema kapsamı

Aşağıdaki eklenti tipleri CPU ve DB’yi daha çok zorlar: - Her sayfada ek hesaplama yapan fiyat/indirim motorları - Çoklu dil/para birimi kuralları - Harici API çağıran ödeme/kargo/ürün zenginleştirme eklentileri

4) Cache katmanlarınızın durumu

Magento 2’nin performans kalbi cache’tir. Bu cache’lerin aktifliği, aynı donanımda farklı sonuç üretir.

Aşağıdaki tabloda “cache yoksa spec neden yetmez?” sorusunun cevabını görebilirsiniz:

Cache durumu	Tipik etki	Speclere yansıyan gerçek sonuç
Tam sayfa cache kapalı	Her istek daha fazla PHP + DB	CPU/worker ihtiyacı artar
Redis/Memcached yok	Session ve data cache yükü yükselir	RAM ihtiyacı artar, TTFB dalgalanır
Varnish yok (opsiyonel)	Hot sayfalarda origin yükü artar	CPU + DB yazma/okuma artar
İndeksler sık güncelleniyor, cron kontrolsüz	Tepe saatlerde reindex/cron çakışması	CPU pikleri ve gecikme

Magento 2 için minimum değil, hedefe göre spec hedefleri

Tek bir evrensel değer vermek yerine “hedef senaryolar” üzerinden net değerler verelim. Bu değerler, doğru cache/ayarla birleştirildiğinde anlamlıdır.

Referans spec hedefleri (başlangıç noktası)

Aşağıdaki hedefleri yeni kurulum veya ciddi yeniden yapılandırma için “starting point” olarak kullanın.

1) Küçük mağaza (yaklaşık düşük trafik)

Ortalama günlük ziyaret: düşük-orta
Ürün ölçeği: küçük/orta
Eklenti sayısı: sınırlı

Hedef: - CPU: 2 vCPU - RAM: 4-6 GB - Storage: SSD/NVMe (tercihen) - Veritabanı: ayrı DB veya en azından yüksek performanslı MySQL/MariaDB

2) Büyüyen mağaza (kampanya + düzenli trafik)

Ortalama trafik orta
Tepe saat belirgin
Layered navigation ve filtreleme aktif

Hedef: - CPU: 4 vCPU - RAM: 8-16 GB - Storage: NVMe SSD - DB: yüksek IOPS + uygun buffer/innodb ayarları

3) Kurumsal ölçek / yoğun kampanya

Eş zamanlılık yüksek
Ürün sayısı büyük
Çoklu cron/indeks işleri

Hedef: - CPU: 8+ vCPU - RAM: 16-32+ GB - Storage: NVMe SSD + yüksek IOPS - DB: ayrı sunucu veya iyi kaynak izolasyonu - Cache: Redis + (uygunsa) Varnish

Not: Bu hedefler “cache ve cron doğru değilse” yetersiz kalır. Tersine, cache doğru çalışıyorsa daha düşük spec ile hedef yakalanabilir.

Hangi kaynaklar gerçekten kritik? CPU mu RAM mi IO mu?

Magento 2’de sık görülen darboğazları, belirtilerle birlikte eşleştirelim. Bu liste “neden spec artırmak zorunda kalıyorum?” sorusunu cevaplar.

TFFB yüksek ama CPU düşükse

Muhtemel nedenler: - PHP-FPM worker sayısı düşük - MySQL sorguları ağır (yetersiz indeks) - Cache miss oranı yüksek (tam sayfa cache/Redis çalışmıyor)

Yapılacaklar: - PHP-FPM process sayısını (ve max requests) yapılandırma politikasıyla denetleyin - DB’de yavaş sorguları izleyin - Cache state’ini doğrulayın (cache türleri açık mı?)

CPU yüksek ama RAM düşük değilse

Muhtemel nedenler: - Cron çakışması (reindex/cron jobları tepe saatlerde) - Aşırı observer/eklenti hesaplama - Output buffering veya yanlış PHP ayarları

Yapılacaklar: - Cron zamanlarını trafik dışına alın - İndeksleme modunu ve job frekansını düzenleyin - Eklenti performansını A/B test edin

Disk/IO yüksek, DB yavaşsa

Muhtemel nedenler: - MySQL/MariaDB’nin disk tabanlı operasyonları (özellikle write-heavy) - yetersiz IOPS veya paylaşımlı/overcommit storage - geçici dosyaların sık yazılması

Yapılacaklar: - NVMe SSD/ayrık DB kaynaklarına geçin - İndeks stratejisini kontrol edin - temporary/table kullanımını izleyin

Doğru barındırma (hosting) tipini seçmek: VDS/VPS mi managed mı?

Magento 2 için “spec şart mı?” sorusunun ikinci yarısı şu: Kaynak izolasyonu var mı?

Paylaşımlı hosting neden riskli kalır?

Magento 2, benzer donanım değerlerinde bile paylaşımlı ortamda dalgalı performans gösterebilir. Özellikle: - Diğer kiracıların CPU/IO etkisi - Kontrolsüz process limitleri - Cache/cron ayarlarına sınırlı erişim

Bu yüzden Magento 2 için genellikle VPS/VDS veya kaynak izolasyonu sunan altyapılar tercih edilir.

VDS/VPS’de kontrol etmeniz gereken 10 teknik başlık

Aşağıdaki maddeler “ciddi spec”i boşa çıkarmadan sonucu aldırır: - PHP-FPM: worker sayısı ve process limitleri - OPcache: opcache aktif mi, doğru memory ayrıldı mı? - Tam sayfa cache: Magento tarafı aktif mi? - Redis (bazen Varnish ile birlikte): session/cache kullanımında doğru entegrasyon var mı? - MySQL/MariaDB: ayrı DB önerisi + uygun buffer ayarları - Cron: job’lar trafik dışına alınıyor mu? - Dosya sistemi: cache ve log yazma politikası (I/O yükünü azaltma) - CDN: statik dosyalar (CSS/JS/image) CDN üzerinden mi? - TLS/HTTP: (mümkünse) HTTP/2 ve HTTP/3 desteği ile bağlantı optimizasyonu - Yedekleme (backup): sık ve geri dönüş testi yapılabiliyor mu?

“Spec artırmak” yerine önce ölçün: Net test yaklaşımı

Magento 2’de doğru kararı hızlandıran şey benchmark değil, “gerçek mağaza senaryosu” testidir.

Ölçüm hedefleri (pratik)

TTFB (Time to First Byte): cache varlığını hızlı teşhis eder
CPU pikleri: cron ve reindex çakışmasını yakalar
DB bağlantı ve sorgu süresi: “Too many connections” gibi sorunlar varsa spes de yetmez

30 dakikalık teşhis planı

Cache açık mı, miss oranı nedir?
Cron job süreleri tepe saatlere sarkıyor mu?
En pahalı 5 sorguyu (slow query) bulun.
PHP-FPM worker sayısını mevcut yükle eşleştirin.
Disk/IO ve DB read/write oranlarını kontrol edin.

Bu adımlar sonrası elde ettiğiniz resme göre spec artırma kararı verin.

NetKıyas karar çerçevesi: Alırken spec + ayar uyumu arayın

Magento 2 hosting seçerken sadece vCPU/RAM sayısına bakmak yerine, sağlayıcının “bu kaynaklar Magento için nasıl kullanılacak?” sorusuna verdiği cevabı arayın.

Aşağıdaki kontrol listesini kullanın:

Sağlayıcıya sorulacak net sorular

PHP-FPM ayarları (worker/process) sizin kontrolünüzde mi?
Redis/Memcached entegrasyonu kurulum desteği var mı?
Tam sayfa cache ve Varnish kullanımı destekleniyor mu?
MySQL/MariaDB sürümü ve performans optimizasyonu (buffer, index önerileri) var mı?
Cron/reindex süreçleri için önerilen zamanlama var mı?
Dosya sistemi ve storage tipi NVMe SSD mi?
Yedekleme (backup) sıklığı ve geri dönüş (restore) testi nasıl yapılır?
İzleme (monitoring): CPU/RAM/DB yavaş sorgu izleme sunuluyor mu?
DDoS/WAF ve güvenlik katmanları hangi seviyede?

Karar tablosu: Spec mi çözüm, yapılandırma mı?

Gözlem	En olası kök neden	Önerilen adım
TTFB yüksek + cache miss	Cache katmanı çalışmıyor	Cache entegrasyonunu düzelt
CPU pik + cron çakışması	Reindex/cron trafikle çakışıyor	Cron zamanlarını düzenle
DB sorguları yavaş + CPU beklenen	İndeks/şema problemi	Yavaş sorgu + indeks optimizasyonu
Disk IO yüksek + DB yavaş	Storage IOPS yetersiz	NVMe/ayrık DB kaynaklarını artır
Too many connections	Bağlantı havuzu/worker uyumsuz	PHP-FPM + DB bağlantı stratejisini düzenle

Sonuç: “Ciddi spec şart mı?” — evet, ama doğru yerde

Magento 2 hosting’de ciddi spec ihtiyacı çoğu projede ortaya çıkar; ancak bu ihtiyaç, cache/cron/DB optimizasyonu yapılmadığında “daha da artar”. Bu yüzden aksiyon sırası net olmalı: Önce cache katmanlarının çalıştığını doğrulayın, cron ve reindex çakışmalarını düzeltin, yavaş sorguları (slow query) tespit edin. Bu adımlardan sonra hâlâ TTFB/DB/IO darboğazları devam ediyorsa CPU/RAM/IO hedeflerini senaryonuza göre yükseltin.

Eğer NetKıyas’ta inceleyeceğiniz paketi seçerken yukarıdaki 10 teknik başlığı sağlayıcı tarafından destekleniyor mu diye doğrularsanız, Magento 2 için ne kadar “ciddi spec” gerektiğini tek seferde doğru yere bağlamış olursunuz.