Teknoloji

Magento ve PrestaShop İçin Hosting Rehberi: CPU, RAM, PHP ve MySQL Ayarları

Magento veya PrestaShop ile kurduğunuz bir e‑ticaret sitesinin kaderi, sadece tema ve eklentilerle değil; seçtiğiniz hosting altyapısı, CPU/RAM kapasitesi ve PHP/MySQL ayarlarıyla da belirleniyor. Aynı yazılım, yanlış yapılandırılmış bir sunucuda saniyelerce bekletebilirken; doğru ayarlar ve doğru kaynaklarla yüzlerce eş zamanlı müşteriyi rahatça taşıyabiliyor. DCHost tarafında onlarca Magento ve PrestaShop mağazasını taşırken gördüğümüz ortak nokta şu: Sorun çoğu zaman “yazılım ağır” değil, altyapı planlaması eksik.

Bu rehberde, Magento ve PrestaShop için kaç vCPU, ne kadar RAM gerektiğini; PHP ve MySQL ayarlarını yüksek trafik için nasıl kurgulamanız gerektiğini adım adım anlatacağız. Amacımız sadece teorik sınırlar değil, pratikte işe yarayan değerler vermek. Kendi mağazanızda uygulayabileceğiniz, gerektiğinde DCHost üzerindeki VPS, dedicated veya colocation altyapınızda kullanabileceğiniz somut öneriler bulacaksınız.

Eğer halihazırda bir Magento/PrestaShop siteniz varsa ve “özellikle yoğun saatlerde neden yavaşlıyoruz?” sorusuna cevap arıyorsanız; ya da yeni bir proje planlayıp baştan doğru kurmak istiyorsanız, bu rehberi bir kapasite planlama ve ayar kontrol listesi gibi kullanabilirsiniz.

Magento ve PrestaShop Mağazalarında Kaynak Planlaması Neden Farklı?

Magento ve PrestaShop her ikisi de PHP + MySQL tabanlı olsa da kaynak tüketim profilleri aynı değil. Özellikle kampanya dönemlerinde aradaki fark net şekilde hissediliyor.

  • Magento, modüler yapısı, gelişmiş sepet/kurallar sistemi ve çok mağazalı mimarisi nedeniyle daha CPU ve RAM aç bir platformdur.
  • PrestaShop daha hafif bir çekirdeğe sahip olsa da; zengin tema/eklenti kullanımı, zayıf cache ayarları ve kötü optimize edilmiş SQL sorguları altında o da rahatlıkla kilitlenebilir.

Magento tarafında detaylı bir inceleme istiyorsanız, Magento için CPU, RAM, NVMe ve Redis dengesini anlattığımız rehberi ayrıca okumanızı öneririz. Benzer şekilde, PrestaShop özelinde daha uygulamalı örnekler için PrestaShop hosting rehberimizde PHP, MySQL, önbellek ve CDN ayarlarını ayrıntılı ele aldık.

Bu yazıda, her iki platformu aynı masaya oturtup; CPU, RAM, PHP ve MySQL’i yüksek trafik odağında yan yana değerlendireceğiz.

Trafikten Kaynağa: vCPU, RAM ve Disk İhtiyacını Hesaplamak

Ziyaretçi Sayısından Eş Zamanlı Kullanıcıya Geçmek

Planlama yaparken hatayı en çok burada görüyoruz: “Aylık 100.000 ziyaretçimiz var, o zaman orta seviye bir VPS yeter” deniyor. Oysa sunucuyu zorlayan metrik eş zamanlı oturum sayısı ve bu oturumların ne kadar “ağır” işlemler yaptığı.

  • Genel kural: Aylık trafik / (30 gün × 8 saat yoğunluk) ≈ yoğun saatlerdeki saatlik ziyaret.
  • Yoğun saatlik ziyaret / 60 ≈ dakikalık ziyaret; burada genelde %10–20’si aynı anda sayfalar arası geziyor.

Daha formül odaklı ilerlemek isterseniz, CPU, RAM ve trafik hesaplamasını ayrıntılı anlattığımız rehbere de göz atabilirsiniz. Aşağıdaki öneriler, DCHost tarafında gözlemlediğimiz tipik senaryolara dayanıyor.

Magento İçin Önerilen Kaynak Aralıkları

  • Küçük mağaza (aylık 20–50 bin ziyaret, aynı anda 10–20 kullanıcı):
    En az 4 vCPU, 8 GB RAM, NVMe SSD (en az 100–200 GB). Tek VPS üzerinde web + veritabanı birlikte olabilir.
  • Orta ölçekli mağaza (aylık 50–200 bin ziyaret, aynı anda 30–70 kullanıcı):
    6–8 vCPU, 16 GB RAM, NVMe SSD (200+ GB). Mümkünse veritabanını ayrı bir VPS’e veya dedicated sunucuya almak avantaj sağlar.
  • Yoğun kampanya mağazası (aylık 200 bin+ ziyaret, kampanyada 100+ eş zamanlı kullanıcı):
    8–16 vCPU, 32+ GB RAM, NVMe RAID yapılandırması. Web ve veritabanı ayrı sunucularda, Redis/Elasticsearch gibi bileşenler için ek kaynak planlanmalı.

Magento, özellikle kategori sayfalarındaki filtreler ve sepet/checkout adımlarında CPU’yu hızlı tüketir. Bu nedenle “tek çekirdeği güçlü” sunucular yerine, çok çekirdekli ve NVMe diskli VPS veya dedicated mimariler tercih etmekte fayda var.

PrestaShop İçin Önerilen Kaynak Aralıkları

  • Küçük mağaza (aylık 10–40 bin ziyaret, aynı anda 5–15 kullanıcı):
    2–4 vCPU, 6–8 GB RAM, SSD/NVMe disk. Web + veritabanı aynı sunucuda çalışabilir.
  • Orta ölçekli mağaza (aylık 40–150 bin ziyaret, aynı anda 20–50 kullanıcı):
    4–6 vCPU, 12–16 GB RAM, tercihen NVMe disk. Cache eklentisi ve OPcache doğru ayarlandığında oldukça stabil çalışır.
  • Yoğun kampanya mağazası (aylık 150 bin+ ziyaret, kampanyada 60+ eş zamanlı kullanıcı):
    6–8 vCPU, 16–24 GB RAM, NVMe SSD. Veritabanı için ayrı VPS veya dedicated sunucu, Redis tabanlı cache ciddi nefes aldırır.

Özetle: Magento’da bir kademe yukarıdan kaynak planlamak çoğu zaman mantıklı; PrestaShop tarafında ise iyi yapılandırılmış bir VPS ile uzun süre dayanabilirsiniz.

CPU: PHP-FPM, MySQL ve Arka Plan İşlerini Dengelemek

CPU, hem PHP-FPM süreçleri hem de MySQL sorguları tarafından tüketilir. Magento ve PrestaShop’ta resim yeniden boyutlama, rapor oluşturma, cron işleri gibi ek yükler de CPU tarafını zorlar.

PHP-FPM İşlem Sayısı ve vCPU İlişkisi

PHP-FPM için yanlış yapılan en kritik hata, “ne kadar çok process o kadar iyi” mantığıyla pm.max_children değerini şişirmek. Ne kadar çok PHP süreci açarsanız, her istek için daha hazır worker bulursunuz; fakat CPU yetersizse hepsi aynı anda boğulur.

  • Genel kural: vCPU × 3–4 civarında pm.max_children ile başlamak mantıklıdır.
  • Örnek: 8 vCPU bir Magento sunucusunda 24–32 arası PHP-FPM child süreci iyi bir başlangıçtır.
  • pm.max_requests değerini 500–1000 aralığında tutarak, bellek sızıntısı oluşturan süreçlerin zamanla yenilenmesini sağlayabilirsiniz.

PHP-FPM ayarlarının mantığını WordPress/WooCommerce üzerinden anlattığımız detaylı PHP-FPM rehberindeki prensipler, Magento ve PrestaShop için de aynen geçerli. Tek fark, Magento’nun genellikle daha yüksek memory_limit ihtiyaç duyması ve her isteğin daha ağır olmasıdır.

MySQL Tarafında CPU Kullanımı

CPU’yu sadece PHP tüketmez; kötü indekslenmiş, karmaşık JOIN’ler içeren veya gereksiz tekrar eden SQL sorguları da kısa sürede CPU’yu tavana vurdurur.

  • Magento tarafında arama/kategori listeleme, raporlar ve üçüncü parti modüllerin oluşturduğu karmaşık sorgular CPU’yu zorlar.
  • PrestaShop’ta ise çok sayıda modülün aynı sayfa yüklenmesinde çalışması ve zayıf indeks kullanımı yaygındır.

Bu nedenle yüksek trafikli bir mağazada, CPU yetmiyor gibi görünse de gerçek sorun çoğu zaman “fazla trafik” değil, optimize edilmemiş sorgulardır. Bu noktada büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberinde anlattığımız yavaş sorgu analizi ve indeks tasarımı adımlarını Magento/PrestaShop veritabanınıza da uygulayabilirsiniz.

RAM: PHP memory_limit, OPcache ve InnoDB Buffer Pool Dengesi

RAM, PHP süreçleri, OPcache, MySQL ve varsa Redis/Memcached arasında paylaşılan kritik bir kaynaktır. Yeterince RAM yoksa, sunucu swap kullanmaya başlar ve gecikme katlanarak artar.

Magento ve PrestaShop İçin PHP memory_limit Ne Olmalı?

PHP tarafında iki kritik sınır var:

  • Web istekleri için kullanılan memory_limit
  • CLI (komut satırı) işlemleri için kullanılan limit (genellikle farklı ini dosyasıyla)

Genel pratik değerler:

  • Magento: Web için 512M, CLI için 768M–1024M aralığı yaygın. Özellikle indexer ve resim yeniden boyutlama işlemleri için yüksek limit gerekir.
  • PrestaShop: Web için 256M–384M çoğu mağaza için yeterli, çok ağır temalar ve çok sayıda modül kullanılan durumlarda 512M tercih edilebilir.

memory_limit, max_execution_time ve upload_max_filesize gibi PHP ayarlarının nasıl birbiriyle dengeleneceğini PHP ayarlarını doğru yapmak rehberinde detaylı anlattık. Magento/PrestaShop için de aynı prensip geçerli; tek fark, CLI scriptleri için ayrı ve daha yüksek bir limit kullanmanızın çoğu zaman şart olması.

OPcache ve RAM Kullanımı

OPcache, PHP dosyalarının derlenmiş halini RAM’de tutarak her istek için yeniden derleme maliyetini ortadan kaldırır. Magento ve PrestaShop gibi çok dosyalı projelerde OPcache boyutunu küçük bırakmak büyük performans kaybı yaratır.

  • opcache.memory_consumption: En az 256M, büyük Magento projelerinde 512M–768M.
  • opcache.max_accelerated_files: 20000+ (Magento için 40000 civarı mantıklı).
  • opcache.validate_timestamps: Canlı ortamda 0 (deploy sonrası manuel reset) tercih edilebilir.

OPcache tarafını derinlemesine ele aldığımız OPcache ayar rehberindeki yaklaşımları, Magento ve PrestaShop projelerinize de uyarlayabilirsiniz; mantık birebir aynı.

MySQL/MariaDB RAM Planlaması (InnoDB Buffer Pool)

Veritabanı tarafında RAM’in asıl gittiği yer InnoDB buffer pool’dur. Ürün, kategori, sipariş gibi tablo verilerini burada saklayarak disk erişimini minimuma indirirsiniz.

  • Web + DB aynı sunucudaysa: Toplam RAM’in %30–40’ını buffer pool’a ayırmak genelde güvenli.
  • DB ayrı bir VPS/dedicated üzerindeyse: RAM’in %50–60’ını buffer pool’a verebilirsiniz.

Örnekler:

  • 16 GB RAM’li tek sunucuda Magento: 6 GB buffer pool, geri kalanı PHP + cache + sistem.
  • 32 GB RAM’li ayrı DB sunucusu: 18–20 GB buffer pool, kalan RAM loglar ve bağlantı cache’leri için.

Burada amaç, sık kullanılan tabloların büyük bölümünü RAM’de tutmak. Yetersiz buffer pool boyutu, diske bağımlılığı artırır ve yoğun saatlerde TTFB’nin şişmesine neden olur.

PHP Sürümü ve php.ini Ayarları: Magento ve PrestaShop’a Göre Ayarlamak

PHP Sürümü Seçimi

Her iki platform da artık PHP 7.4 öncesini desteklemeyi bırakma eğiliminde. Güvenlik ve performans için:

  • Magento 2.4.x için genellikle PHP 8.1 veya daha yenisi önerilir (versiyon notlarını mutlaka kontrol edin).
  • PrestaShop 1.7+ sürümleri için PHP 7.4–8.1 aralığı sık kullanılıyor; 8.2 desteği için kullanılan modüllerin uyumluluğunu kontrol etmek şart.

Canlı ortamda PHP sürümü yükseltirken mutlaka staging ortamında test yapmanızı ve DCHost üzerinde barındırıyorsanız, staging ortamı için noindex, parola ve IP kısıtlama stratejilerini uygulamanızı öneriyoruz.

Kritik php.ini Parametreleri

Magento ve PrestaShop projelerinde özellikle şu ayarlar kritik:

  • memory_limit: Magento web 512M, CLI 768M–1024M. PrestaShop 256M–512M.
  • max_execution_time: Web için 60–120 sn, CLI scriptleri için 600+ (özellikle indexer ve import işlemleri).
  • max_input_vars: Büyük formlar ve çok dil seçeneği olan panellerde 3000–5000 aralığı mantıklı.
  • upload_max_filesize ve post_max_size: Ürün görselleri ve CSV import’lara göre 32–128 MB aralığında.
  • realpath_cache_size: Magento/Presta gibi çok dosyalı projelerde 128K–256K altına düşmemeli.

Bu değerleri belirlerken mutlaka toplam RAM’i ve PHP-FPM process sayısını birlikte düşünün: Örneğin 8 GB RAM’li bir sunucuda 512M memory_limit ile 40 PHP process açarsanız, teorik olarak 20 GB’tan fazla bellek taahhüt etmiş olursunuz. Bu nedenle hem memory_limit hem pm.max_children değerlerini kontrollü artırmak şart.

MySQL/MariaDB Ayarları: Yüksek Trafiğe Dayanıklı Konfigürasyon

MySQL tarafında “default” ayarlarla bırakılmış çok fazla Magento/PrestaShop mağazası görüyoruz. Oysa birkaç temel ayarın düzeltilmesi bile yoğun saatlerde hissedilir fark yaratıyor.

Temel InnoDB Ayarları

  • innodb_buffer_pool_size: Bir önceki bölümde anlattığımız gibi toplam RAM’e göre %30–60 arasında planlanmalı.
  • innodb_log_file_size: 512M–1G aralığı, yüksek yazma trafiğinde disk I/O’yu azaltır.
  • innodb_flush_log_at_trx_commit: Tam veri güvenliği için 1, performans için 2 tercih edilebilir (riski bilerek).

Bağlantı ve Sorgu Ayarları

  • max_connections: PHP-FPM child sayınız + margin (örneğin 32 PHP child için 80–100 bağlantı).
  • thread_cache_size: 50–100 aralığı, sık açılıp kapanan bağlantıların maliyetini düşürür.
  • tmp_table_size ve max_heap_table_size: 64M–256M aralığı, karmaşık sorgularda diske dökülmeyi azaltır.
  • slow_query_log ve long_query_time: 0.5–1 saniyeden uzun sorguları kaydedip periyodik analiz etmek için mutlaka aktif edin.

Magento ve PrestaShop’un çekirdeği genel olarak optimize; performansı asıl bozan çoğu zaman modüllerin eklediği sorgular ve zayıf indeksler. Düzenli olarak slow query log analiz etmek ve kritik tablolarda eksik indeksleri tamamlamak, yüksek trafikte CPU ihtiyacını ciddi düşürür.

Altyapı Seçimi: paylaşımlı hosting, VPS, Dedicated ve Colocation

Magento ve PrestaShop gibi e‑ticaret odaklı, ağır PHP uygulamaları için altyapı seçimi de en az ayarlar kadar önemli.

  • Paylaşımlı hosting: Küçük PrestaShop mağazaları için kısa süreli bir başlangıç olabilir; ancak CPU ve IO limitleri nedeniyle Magento için genelde yetersiz kalır.
  • VPS: İzole kaynaklar, root erişimi ve esnek ölçekleme sayesinde her iki platform için de pratik çözümdür. NVMe diskli 4–8 vCPU’lu bir VPS, orta ölçekli mağazaların çoğunu rahatça taşır.
  • Dedicated sunucu: Yüksek trafik, büyük kataloglar ve çok mağazalı Magento/PrestaShop projelerinde, tek güçlü dedicated veya birkaç VPS’ten oluşan dağıtık mimari gerekir.
  • Colocation: Kendi donanımını yöneten, özel güvenlik/gelişmiş ağ ihtiyacı olan orta-büyük işletmeler için uygundur. Magento/PrestaShop kümelerini kendi fiziksel sunucularınız üzerinde DCHost veri merkezlerinde barındırabilirsiniz.

Hangi aşamada hangi altyapıya geçmeniz gerektiğini, e‑ticaret genelinde anlattığımız e‑ticaret siteleri için hosting çözümleri rehberi ile birlikte okursanız, yol haritanız çok daha netleşir.

Canlıya Çıkmadan Önce: Load Test, İzleme ve Emniyet Payı

Doğru CPU, RAM, PHP ve MySQL ayarlarını yaptıktan sonra bile, asıl sınav sahada verilir. Özellikle kampanya ve sezonluk yoğunluk öncesi mutlaka yük testi yapmanızı öneriyoruz.

  • Kampanyada beklediğiniz eş zamanlı kullanıcı sayısını simüle edin.
  • Sepet ve ödeme adımlarını ayrı ayrı test ederek dar boğazları bulun.
  • CPU, RAM, disk IO ve MySQL bekleme sürelerini izleyin.

Bu konuda nereden başlayacağınızı bilmiyorsanız, trafik patlamasından önce load test rehberimizde k6, JMeter ve Locust gibi araçlarla kapasite ölçmeyi adım adım anlattık. DCHost üzerinde barınan projelerinizde, test sonuçlarına göre vCPU/RAM arttırımını, disk ve ağ tarafında yapılması gereken optimizasyonları birlikte planlayabiliyoruz.

Son olarak, her hesaplamaya %20–30 arası emniyet payı koymak iyi bir pratiktir. Böylece beklenmedik trafik sıçramalarında da Magento veya PrestaShop mağazanız nefes almaya devam eder.

Özet ve Yol Haritası: Magento/PrestaShop Mağazanızı Yüksek Trafiğe Hazırlamak

Magento ve PrestaShop, doğru kurulduğunda çok güçlü e‑ticaret platformları; fakat yanlış kaynak planlaması ve varsayılan ayarlarla bırakıldıklarında, en basit kampanyada bile yavaşlayan ve hata veren mağazalara dönüşebiliyorlar. Bu rehberde, pratikte en çok işinize yarayacak başlıkları öne çıkardık:

  • Gerçek ihtiyacı belirlerken aylık ziyaret değil, eş zamanlı kullanıcı sayısına odaklanın.
  • Magento için PrestaShop’a göre her zaman bir kademe yüksek CPU ve RAM planlayın.
  • PHP-FPM process sayısını vCPU ile dengeli tutun; memory_limit ve max_children değerlerini birlikte ele alın.
  • OPcache ve InnoDB buffer pool’u cömert ama kontrollü ayarlayın; swap’e düşmekten kaçının.
  • MySQL slow query log’u aktif edip düzenli analiz edin; indeks ve sorgu optimizasyonunu ihmal etmeyin.
  • Yoğun dönemlerden önce mutlaka load test yapın ve sonuçlara göre kaynakları yeniden boyutlandırın.

Eğer mevcut Magento veya PrestaShop mağazanız DCHost dışında bir altyapıda sorun yaşıyorsa ya da yeni bir projeyi daha baştan doğru kurgulamak istiyorsanız, ekibimizle birlikte CPU, RAM, PHP ve MySQL ayarlarının tamamını gözden geçirebilir, size özel VPS, dedicated sunucu veya colocation mimarisini birlikte tasarlayabiliriz. Doğru planlama ile, yoğun kampanya dönemlerinde bile mağazanızın akıcı ve güvenilir kalması mümkün.

Sıkça Sorulan Sorular

Magento, PrestaShop’a göre belirgin şekilde daha ağır bir platform. Küçük bir mağaza için (aylık 20–50 bin ziyaret, 10–20 eş zamanlı kullanıcı) en az 4 vCPU ve 8 GB RAM öneriyoruz. Orta ölçekli mağazalarda 6–8 vCPU ve 16 GB RAM, yoğun kampanya dönemlerinde ise 8–16 vCPU ve 32+ GB RAM gerçekçi aralıklar. Ayrıca NVMe disk kullanmak, özellikle kategori ve arama sorgularında ciddi performans farkı yaratıyor. Elbette katalog büyüklüğü, tema/eklenti sayısı ve entegrasyonlar da ihtiyacı etkiliyor; bu yüzden yük testi yapıp sonuçlara göre ayar yapmak en sağlıklısı.

Çok küçük, az ürünlü ve düşük trafikli PrestaShop mağazaları için kısa süreliğine paylaşımlı hosting düşünülebilir; ancak birkaç bin ürün, çok dilli yapı veya kampanya trafiği planlıyorsanız, izole kaynaklara sahip bir VPS çok daha güvenli. VPS üzerinde kendi PHP, MySQL, OPcache ve cache (Redis/Memcached) ayarlarınızı özgürce yapabilir, gerektiğinde dikey olarak vCPU/RAM artırabilirsiniz. Ayrıca log, izleme ve yedekleme stratejilerini de esnek şekilde kurgulamak mümkün. Özetle, PrestaShop’u ciddiye alıyorsanız orta vadede VPS’e geçmek neredeyse kaçınılmaz.

Güvenlik ve performans açısından PHP 7.4 ve altı kesinlikle tercih edilmemeli. Magento 2.4 serisi için yaygın ve destekli seçim PHP 8.1; bazı sürümler 8.2’yi de destekliyor. PrestaShop 1.7+ sürümlerinde ise genellikle 7.4–8.1 aralığı kullanılıyor; 8.2’de tüm modüllerin uyumlu olup olmadığını iyi kontrol etmeniz şart. Geçiş öncesinde mutlaka staging ortamında test yapın, hata loglarını inceleyin ve OPcache ayarlarını yeni sürüme göre yeniden optimize edin. DCHost üzerinde barındırıyorsanız, aynı sunucuda birden fazla PHP sürümünü paralel kullanıp geçişi kademeli yönetmeniz mümkün.

Öncelikle InnoDB motoru kullanmalı ve innodb_buffer_pool_size değerini toplam RAM’e göre %30–60 aralığında planlamalısınız. Ardından max_connections değerini PHP-FPM child sayınıza göre ayarlayıp, thread_cache_size ve tmp_table_size gibi parametreleri yükselterek sık kullanılan sorguların RAM’de çalışmasını sağlamalısınız. Slow query log’u aktifleştirip 0.5–1 saniyeyi aşan sorguları düzenli analiz etmek, eksik indeksleri tamamlamak ve gereksiz JOIN’leri sadeleştirmek çok önemli. Böylece aynı donanım üzerinde daha fazla trafiği, daha düşük CPU kullanımıyla taşıyabilirsiniz.

Hazırlık için mutlaka gerçekçi bir yük testi yapmanız gerekiyor. Önce yoğun saatte beklediğiniz eş zamanlı kullanıcı sayısını hesaplayıp, bu değeri k6, JMeter veya Locust gibi araçlarla simüle edebilirsiniz. Özellikle sepet ve ödeme adımları, ürün filtreleme ve arama sayfalarını ayrı ayrı test etmek önemli. Test sırasında CPU, RAM, disk IO, MySQL bekleme süreleri ve hata oranlarını izleyin. Darboğaz gördüğünüz noktalarda PHP-FPM, MySQL ve önbellek ayarlarını revize edip testi tekrarlayın. DCHost ekibi olarak, bu süreçte elde ettiğiniz metriklere göre VPS veya dedicated kaynaklarınızı yeniden boyutlandırmanızda da destek olabiliyoruz.