Magento and PrestaShop Hosting Guide: CPU, RAM, PHP and MySQL Tuning

High-traffic Magento and PrestaShop stores are unforgiving. If CPU, RAM, PHP or MySQL settings are off by just a bit, you start seeing slow product pages, timeouts in checkout, and locked database connections at peak hours. In this guide, we will walk through concrete, real-world hosting settings for Magento and PrestaShop: how many vCPUs and how much RAM you actually need, what to put in php.ini and PHP-FPM, and which MySQL parameters matter most for busy e‑commerce catalogs. The goal is simple: keep product listing, cart and payment steps fast and stable, even when campaigns or seasonal sales push your traffic up. We will focus on settings that you can apply on a VPS, dedicated server or powerful shared environment, and show you how we approach these projects at dchost.com when sizing and tuning infrastructure for growing online stores.

Magento vs PrestaShop: Resource Profile And Hosting Basics

Before touching any config file, it helps to understand how Magento and PrestaShop spend CPU and RAM, and where the bottlenecks usually appear.

How Magento Uses Server Resources

Magento (especially Magento 2) is heavy by design. It relies on many PHP classes, complex dependency injection and a thick layer of business logic. This leads to:

• High CPU usage per request, especially on category and search pages.
• Significant RAM usage per PHP-FPM worker, often 256–512 MB per process when extensions and custom modules are loaded.
• Intensive MySQL queries, particularly on product listing, layered navigation and checkout steps.
• Heavy use of caches (block, full page, config) where Redis is strongly recommended.

This is why Magento typically needs more CPU, RAM and faster disks (NVMe) than a similarly sized WooCommerce or classic PHP site. In our detailed Magento hosting article on CPU, RAM, NVMe and Redis requirements, we consistently see CPU and disk IOPS as the first bottlenecks on underpowered servers.

How PrestaShop Uses Server Resources

PrestaShop is generally lighter than Magento, but high-traffic stores with many modules can still hit resource limits. Typical characteristics:

• Moderate CPU usage per request, but sensitive to bad modules or unoptimized themes.
• Lower memory footprint than Magento per PHP worker, but can still reach 256 MB or more on complex stores.
• Database load dominated by product listing, cart operations and stats/logs tables if not cleaned.
• Cache can be file based, Memcached or Redis depending on version and configuration.

We have already covered platform-specific tuning in our dedicated PrestaShop hosting guide for PHP, MySQL, caching and CDN. In this article we focus on cross-platform hosting decisions: CPU, RAM and database settings that help both Magento and PrestaShop at scale.

When Shared Hosting Is Not Enough

Shared hosting is fine for small or new stores, but high-traffic Magento or PrestaShop almost always need a VPS or dedicated server. Typical indicators that you have outgrown basic shared hosting:

• Admin panel is slow during product import or mass price updates.
• Checkout sometimes returns 502/504 errors at busy times.
• Hosting control panel shows CPU or IO usage staying at or near 100% for long periods.
• You cannot adjust critical settings like innodb_buffer_pool_size or PHP-FPM pool limits.

On dchost.com we usually place high-traffic Magento and large PrestaShop sites on VPS or dedicated servers with NVMe disks and full root or panel-level access, so all tuning discussed below is possible.

CPU and RAM Sizing For High-Traffic Magento And PrestaShop

There is no single magic number, but we can give realistic ranges for different traffic levels. These assume well-optimized themes and a reasonable number of modules/extensions.

Baseline Sizing By Traffic Level

Think in terms of concurrent users (visitors actively loading pages at the same time), not only monthly pageviews.

• Small / new store (up to ~10 concurrent users, a few orders per hour):
  Magento: 2 vCPU, 4–6 GB RAM
  PrestaShop: 2 vCPU, 4 GB RAM
• Growing store (~30–80 concurrent users, 50–300 orders/day):
  Magento: 4–6 vCPU, 8–16 GB RAM
  PrestaShop: 4 vCPU, 8–12 GB RAM
• High-traffic store (100+ concurrent users, 300–2000 orders/day):
  Magento: 8–16 vCPU, 16–32 GB RAM
  PrestaShop: 6–12 vCPU, 16–24 GB RAM

These ranges assume a single application + database server. Once you get beyond these, you should consider separating the database to its own VPS/dedicated machine, similar to the approach we describe for WooCommerce in our article on when a separate database and cache server becomes logical.

CPU: Why Single-Core Speed Matters

Both Magento and PrestaShop benefit from high single-core performance. PHP requests are parallelized across cores, but an individual request still runs mostly on one core. That means:

• Prefer fewer, faster cores over many very slow cores.
• Watch CPU steal time on VPS (e.g. via top or htop). If steal time is high, change plan or node.
• Monitor load average vs core count. Sustained load higher than 1x–1.5x number of vCPUs usually means you are CPU bound.

We go deeper into selecting vCPU counts for PHP workloads in our guide on how many vCPUs and how much RAM you really need; the same logic applies to Magento and PrestaShop.

RAM: Room For PHP, MySQL And Cache

RAM requirements come from three main consumers:

• PHP-FPM workers (Magento workers can easily hit 300–400 MB each; PrestaShop a bit less).
• MySQL/MariaDB buffer pool and caches.
• Redis/Memcached for application and session caching.

To size RAM, do a quick back-of-the-envelope calculation:

1. Estimate realistic max PHP-FPM workers (we will calculate this in the PHP section).
2. Multiply workers by estimated memory per worker (e.g. 300 MB for Magento, 200 MB for PrestaShop).
3. Add MySQL memory (usually 25–40% of total RAM on a single-server setup).
4. Add Redis/Memcached (usually 512 MB to several GB depending on catalog size).
5. Leave at least 10–20% RAM free for OS and filesystem cache.

If the math does not fit into your current RAM, you either reduce PHP workers (and accept less concurrency), move MySQL to another server, or upgrade RAM.

PHP And PHP-FPM Settings For Magento And PrestaShop

Once CPU and RAM are sized, PHP tuning is the next big win. Many stores run with default php.ini values that are fine for blogs, but not for heavy e‑commerce.

Key php.ini Values For High‑Traffic Stores

These values are good starting points for a mid-sized store (adjust upwards for larger setups):

• memory_limit
  Magento: 512M–768M
  PrestaShop: 256M–512M
  Use higher values for CLI tasks like reindex and bulk import.
• max_execution_time
  Web requests: 60–90 seconds (longer risks leaving stuck PHP workers).
  CLI (php -d max_execution_time=0) for long running tasks like indexing.
• max_input_time: 60–120 seconds, especially if you have large forms or imports.
• post_max_size: 32M–128M, depending on your largest admin uploads.
• upload_max_filesize: 32M–128M (do not set lower than post_max_size).
• realpath_cache_size: 256K–512K; Magento benefits from higher values due to many files.

We explain these settings in more generic detail in our article on choosing the right memory_limit, max_execution_time and upload_max_filesize. For Magento and PrestaShop, it is usually worth being a bit more generous than on regular content sites, as long as you monitor for runaway scripts.

OPcache: Critical For Magento And Helpful For PrestaShop

For both platforms, OPcache must be enabled. Without it, PHP will compile Magento’s code on every request, which is a non-starter under load.

Good baseline OPcache configuration for a mid-sized store:

• opcache.enable = 1
• opcache.memory_consumption = 256
• opcache.interned_strings_buffer = 16
• opcache.max_accelerated_files = 20000–40000
• opcache.validate_timestamps = 1 (0 in highly controlled environments + manual cache clear)
• opcache.revalidate_freq = 60

Larger Magento installations may need 512 MB or more of OPcache memory. We discuss these parameters in more detail in our guide to PHP OPcache settings and best configurations; you can apply the same principles to both Magento and PrestaShop.

PHP-FPM Pool Settings: pm, pm.max_children And Friends

PHP-FPM controls how many PHP workers can run concurrently. This is where you marry your RAM sizing with concurrency needs.

• pm: Use dynamic for most setups. Static only if you know exactly how many workers you want.
• pm.max_children: The most critical setting. A practical way to calculate:
  pm.max_children = (RAM_for_PHP / average_worker_memory)
  Example for Magento: If you dedicate 8 GB of RAM to PHP and each worker uses about 350 MB, you can afford ~23 workers. Set pm.max_children to 20 for safety.
• pm.start_servers: 20–30% of pm.max_children.
• pm.min_spare_servers: 20–30% of pm.max_children.
• pm.max_spare_servers: 50–60% of pm.max_children.
• pm.max_requests: 300–500 (recycle workers to mitigate memory leaks).

For PrestaShop, worker memory is usually lower, so you can run more workers with the same RAM. For example, with 8 GB for PHP and ~220 MB per worker, pm.max_children around 30 is realistic.

If you are new to PHP-FPM pool tuning, our article on PHP-FPM settings and calculating pm.max_children and pm.max_requests for WordPress and WooCommerce provides a very similar step-by-step method you can reuse here.

MySQL / MariaDB Settings For Busy Magento And PrestaShop Stores

Many e‑commerce slowdowns come from database bottlenecks: full table scans, disk-bound buffer pools, temp tables on disk. The right MySQL/MariaDB configuration dramatically reduces CPU and IO load.

InnoDB Buffer Pool Size: The Big Lever

Magento and PrestaShop should run on InnoDB only. The innodb_buffer_pool_size determines how much data and indexes can be cached in RAM.

• On a dedicated database server, set buffer pool to 60–70% of total RAM.
• On a single server with web + DB, 25–40% of RAM is more realistic; the rest is needed for PHP, Redis and OS.

Example: A single 16 GB server running both web and DB services:

• 8 GB for PHP-FPM + OPcache.
• 4 GB for InnoDB buffer pool.
• 1–2 GB for Redis/Memcached.
• 2–3 GB for OS and filesystem cache.

If you see high buffer pool reads from disk and high IOwait in tools like iostat, consider moving MySQL to its own server so you can grow buffer_pool_size without starving PHP.

Other Important InnoDB Settings

Beyond buffer pool, a few parameters consistently help e‑commerce workloads:

• innodb_log_file_size: 512M–1G per log file for medium to large stores. Too small causes frequent flushes and IO spikes.
• innodb_log_buffer_size: 64M–256M, higher if you have many concurrent writes.
• innodb_flush_log_at_trx_commit: Values:
  1 = safest, most disk IO (log flushed every transaction).
  2 = safer performance trade-off (log written every transaction, flushed every second).
  Many stores use 2 on NVMe storage, accepting a small risk window to gain better write performance.
• innodb_flush_method: O_DIRECT (or O_DIRECT_NO_FSYNC) to reduce double buffering on Linux.
• innodb_file_per_table: 1 (should be enabled on modern installations).

We discuss these patterns and slow query analysis in depth for WooCommerce in our article on MySQL/InnoDB tuning checklists; the same queries (catalog, cart, orders) are similar on Magento and PrestaShop.

Connection, Temp Table And Query Cache Settings

• max_connections: Do not just set a huge number. Start with 150–300 and monitor. Too many connections + insufficient RAM = swapping and collapse.
• tmp_table_size and max_heap_table_size: Set both equal, e.g. 64M–256M. When too low, many queries spill to disk.
• query_cache_type = 0 and query_cache_size = 0 on modern MySQL; query cache is deprecated/removed and hurts scaling.

Monitor for the ratio of created_tmp_disk_tables vs created_tmp_tables; if a large portion go to disk, increase tmp_table_size / max_heap_table_size and optimize queries or indexes.

Cache, Sessions And Background Jobs

CPU, RAM, PHP and MySQL tuning get you far, but high-traffic e‑commerce really shines when cache and background processing are used correctly.

Application Cache: Redis Or Memcached

For Magento, Redis is the standard choice for:

• Full page cache.
• Default/metadata cache.
• Sessions (optional but recommended).

PrestaShop can use file cache, Memcached or Redis (depending on version/modules). For high-traffic, we recommend Redis or Memcached; file cache quickly becomes a filesystem bottleneck on NVMe-backed but busy systems.

On a combined server, dedicate 512M–4G of RAM to Redis depending on catalog size and cache strategy. Use separate Redis databases or instances for full page cache vs sessions, and enable persistence (AOF or RDB) if you cannot afford losing cache or sessions on restart.

PHP Sessions: Avoid File Storage At Scale

File-based PHP sessions work on small sites, but for busy stores they cause disk IO and lock contention. Better options:

• Redis for sessions: fast, centralized, can scale out later.
• Memcached for sessions: also fast but no persistence (sessions lost if it restarts).

We explain pros and cons of each approach in our platform-agnostic guide to choosing PHP session and cache storage between files, Redis and Memcached; the same trade-offs apply one-to-one to Magento and PrestaShop.

Cron And Background Jobs

Both Magento and PrestaShop rely on cron for important tasks:

• Reindexing and cache warm-up.
• Abandoned cart emails, newsletters and marketing automations.
• Order status updates, stock sync with ERPs or marketplaces.

On high-traffic servers:

• Run cron via system cron, not via web hits.
• Schedule resource-heavy jobs (reindex, big imports) outside absolute peak hours.
• On larger setups, consider a separate worker server for heavy background tasks so they do not compete with frontend traffic.

Practical Sizing Scenarios For Magento And PrestaShop

Let us make this concrete with a few example scenarios from typical dchost.com customer profiles. These are simplified, but they show how all the pieces (CPU, RAM, PHP, MySQL) come together.

Scenario 1: Medium PrestaShop Store With Campaign Spikes

Profile:

• 20–50 concurrent users at peak.
• 3000+ products.
• Up to 300 orders/day during campaigns.

Recommended single-server starting point:

• 6 vCPU, 12–16 GB RAM, NVMe SSD.
• PHP-FPM: pm.dynamic, pm.max_children ~30 (estimate 220 MB per worker, ~6.5 GB used at peak), pm.max_requests = 400.
• php.ini: memory_limit = 512M, max_execution_time = 60, upload_max_filesize = 64M.
• OPcache: 256 MB memory, 20000–30000 max_accelerated_files.
• MySQL: innodb_buffer_pool_size ~4 GB, innodb_log_file_size 512M, tmp_table_size/max_heap_table_size 128M.
• Redis: 1 GB for cache + sessions.

Monitoring focus: ensure CPU stays under 70% on average during peak, and that MySQL does not show high disk IOwait. If cart or checkout pages get slower during email campaigns, you may need more CPU or separate MySQL.

Scenario 2: Busy Magento Store With Heavy Extensions

Profile:

• 80–150 concurrent users.
• 10000+ products, complex pricing rules and custom modules.
• 1000+ orders/day during big events.

Recommended architecture:

• Application VPS/dedicated: 12–16 vCPU, 24–32 GB RAM, NVMe SSD.
• Database VPS/dedicated: 8–12 vCPU, 32 GB RAM, NVMe SSD, tuned for MySQL/MariaDB.

Application server settings:

• PHP-FPM: pm.dynamic, pm.max_children 50–70 (estimate 350 MB per worker, ~24 GB RAM reserved), pm.max_requests 400.
• php.ini: memory_limit 768M for web, 1024M for CLI reindex; max_execution_time 90.
• OPcache: 512 MB, 40000 max_accelerated_files.
• Redis: 2–4 GB for cache + sessions, separate instances/DBs per purpose.

Database server settings:

• innodb_buffer_pool_size ~20–24 GB.
• innodb_log_file_size 1G, innodb_flush_log_at_trx_commit = 1 or 2 depending on risk tolerance.
• tmp_table_size/max_heap_table_size 256M+
• max_connections 300–400 (backed by enough RAM to handle it).

At this scale, you should also plan for read replicas or more advanced strategies like ProxySQL read/write splitting if reporting or search puts heavy read load on the database.

Scenario 3: Growing Store Migrating From Shared Hosting To VPS

Profile:

• Magento or PrestaShop store currently on shared hosting.
• Frequent 503 / 504 errors during campaigns.
• Cannot edit MySQL or PHP-FPM settings.

Typical migration step at dchost.com:

• Move to a 4–6 vCPU, 8–12 GB RAM VPS with NVMe.
• Enable OPcache and configure PHP-FPM pools as described above.
• Tune MySQL buffer pool and temp table sizes.
• Move sessions and application cache to Redis.
• Set up proper cron jobs and disable any web-based cron triggers.

This alone usually removes the worst slowdowns. From there, we gradually refine settings based on real monitoring as traffic grows. If you are planning this kind of move, our guide on moving from shared hosting to a VPS without downtime walks through the DNS and cutover side in detail.

Monitoring, Load Testing And When To Upgrade

All these settings are starting points. The real confirmation comes from watching the server under real traffic and scheduled load tests.

Key Metrics To Watch

• CPU usage: Aim for sustained averages below 70% at peak. Short spikes are fine.
• RAM and swap: Swapping under load is a red flag; consider adding RAM or reducing PHP workers.
• Disk IOwait: Long waits often indicate undersized MySQL buffer pool or slow disk.
• MySQL slow query log: Focus on catalog, cart and checkout queries; add indexes or rewrite problematic queries.
• PHP-FPM status: Maxed out workers (all busy) means request queueing and increasing response times.

Load Testing Before Big Campaigns

Before major campaigns or seasonal peaks, run load tests that simulate real users browsing categories and completing checkout. This lets you identify bottlenecks while there is still time to tune or upgrade. We recommend a process very similar to what we describe in our guide on load testing your hosting before traffic spikes. Apply it to your Magento or PrestaShop store with realistic user flows and ramp-up patterns.

Clear Signals It Is Time To Scale Up Or Out

• CPU and RAM are persistently near capacity despite reasonable tuning.
• MySQL slow query log keeps growing even after indexing and buffer pool tuning.
• PHP-FPM frequently hits pm.max_children and logs slow requests.
• Checkout latency grows significantly faster than catalog page latency under load.

At that point, options include:

• Upgrading to more vCPUs/RAM on the same VPS or dedicated server.
• Splitting application and database onto separate servers.
• Adding dedicated servers or additional VPS instances behind a load balancer.

Wrapping Up: Putting It All Together On dchost.com

High-traffic Magento and PrestaShop hosting is not about one magic parameter. It is about matching CPU, RAM, PHP-FPM pools, OPcache, MySQL buffer pool and cache layers to your actual traffic profile and growth plans. Start by sizing vCPUs and RAM realistically, then apply the PHP and MySQL settings we outlined as baselines. Move sessions and application caches to Redis, keep cron jobs off the critical path, and use monitoring plus load tests to verify your assumptions before major campaigns.

At dchost.com, we design Magento and PrestaShop stacks exactly this way: begin with a clean, well-tuned single server or VPS, then split roles (database, cache, search, workers) only when metrics say it is time. If you are unsure how many vCPUs and how much RAM your store needs, or how to translate these examples into a concrete VPS or dedicated server plan, our team can review your current traffic, extensions and growth targets and suggest a clear capacity roadmap. Reach out to us with your current hosting specs and a rough order/traffic profile, and we will help you turn these best practices into a stable, fast Magento or PrestaShop infrastructure you can trust during your busiest days.