{"id":4677,"date":"2026-02-07T15:35:42","date_gmt":"2026-02-07T12:35:42","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/magento-and-prestashop-hosting-guide-cpu-ram-php-and-mysql-tuning\/"},"modified":"2026-02-07T15:35:42","modified_gmt":"2026-02-07T12:35:42","slug":"magento-and-prestashop-hosting-guide-cpu-ram-php-and-mysql-tuning","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/magento-and-prestashop-hosting-guide-cpu-ram-php-and-mysql-tuning\/","title":{"rendered":"Magento and PrestaShop Hosting Guide: CPU, RAM, PHP and MySQL Tuning"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>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\u2011commerce 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 <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or powerful shared environment, and show you how we approach these projects at dchost.com when sizing and tuning infrastructure for growing online stores.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Magento_vs_PrestaShop_Resource_Profile_And_Hosting_Basics\"><span class=\"toc_number toc_depth_1\">1<\/span> Magento vs PrestaShop: Resource Profile And Hosting Basics<\/a><ul><li><a href=\"#How_Magento_Uses_Server_Resources\"><span class=\"toc_number toc_depth_2\">1.1<\/span> How Magento Uses Server Resources<\/a><\/li><li><a href=\"#How_PrestaShop_Uses_Server_Resources\"><span class=\"toc_number toc_depth_2\">1.2<\/span> How PrestaShop Uses Server Resources<\/a><\/li><li><a href=\"#When_Shared_Hosting_Is_Not_Enough\"><span class=\"toc_number toc_depth_2\">1.3<\/span> When Shared Hosting Is Not Enough<\/a><\/li><\/ul><\/li><li><a href=\"#CPU_and_RAM_Sizing_For_High-Traffic_Magento_And_PrestaShop\"><span class=\"toc_number toc_depth_1\">2<\/span> CPU and RAM Sizing For High-Traffic Magento And PrestaShop<\/a><ul><li><a href=\"#Baseline_Sizing_By_Traffic_Level\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Baseline Sizing By Traffic Level<\/a><\/li><li><a href=\"#CPU_Why_Single-Core_Speed_Matters\"><span class=\"toc_number toc_depth_2\">2.2<\/span> CPU: Why Single-Core Speed Matters<\/a><\/li><li><a href=\"#RAM_Room_For_PHP_MySQL_And_Cache\"><span class=\"toc_number toc_depth_2\">2.3<\/span> RAM: Room For PHP, MySQL And Cache<\/a><\/li><\/ul><\/li><li><a href=\"#PHP_And_PHP-FPM_Settings_For_Magento_And_PrestaShop\"><span class=\"toc_number toc_depth_1\">3<\/span> PHP And PHP-FPM Settings For Magento And PrestaShop<\/a><ul><li><a href=\"#Key_phpini_Values_For_HighTraffic_Stores\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Key php.ini Values For High\u2011Traffic Stores<\/a><\/li><li><a href=\"#OPcache_Critical_For_Magento_And_Helpful_For_PrestaShop\"><span class=\"toc_number toc_depth_2\">3.2<\/span> OPcache: Critical For Magento And Helpful For PrestaShop<\/a><\/li><li><a href=\"#PHP-FPM_Pool_Settings_pm_pmmax_children_And_Friends\"><span class=\"toc_number toc_depth_2\">3.3<\/span> PHP-FPM Pool Settings: pm, pm.max_children And Friends<\/a><\/li><\/ul><\/li><li><a href=\"#MySQL_MariaDB_Settings_For_Busy_Magento_And_PrestaShop_Stores\"><span class=\"toc_number toc_depth_1\">4<\/span> MySQL \/ MariaDB Settings For Busy Magento And PrestaShop Stores<\/a><ul><li><a href=\"#InnoDB_Buffer_Pool_Size_The_Big_Lever\"><span class=\"toc_number toc_depth_2\">4.1<\/span> InnoDB Buffer Pool Size: The Big Lever<\/a><\/li><li><a href=\"#Other_Important_InnoDB_Settings\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Other Important InnoDB Settings<\/a><\/li><li><a href=\"#Connection_Temp_Table_And_Query_Cache_Settings\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Connection, Temp Table And Query Cache Settings<\/a><\/li><\/ul><\/li><li><a href=\"#Cache_Sessions_And_Background_Jobs\"><span class=\"toc_number toc_depth_1\">5<\/span> Cache, Sessions And Background Jobs<\/a><ul><li><a href=\"#Application_Cache_Redis_Or_Memcached\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Application Cache: Redis Or Memcached<\/a><\/li><li><a href=\"#PHP_Sessions_Avoid_File_Storage_At_Scale\"><span class=\"toc_number toc_depth_2\">5.2<\/span> PHP Sessions: Avoid File Storage At Scale<\/a><\/li><li><a href=\"#Cron_And_Background_Jobs\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Cron And Background Jobs<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Sizing_Scenarios_For_Magento_And_PrestaShop\"><span class=\"toc_number toc_depth_1\">6<\/span> Practical Sizing Scenarios For Magento And PrestaShop<\/a><ul><li><a href=\"#Scenario_1_Medium_PrestaShop_Store_With_Campaign_Spikes\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Scenario 1: Medium PrestaShop Store With Campaign Spikes<\/a><\/li><li><a href=\"#Scenario_2_Busy_Magento_Store_With_Heavy_Extensions\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Scenario 2: Busy Magento Store With Heavy Extensions<\/a><\/li><li><a href=\"#Scenario_3_Growing_Store_Migrating_From_Shared_Hosting_To_VPS\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Scenario 3: Growing Store Migrating From Shared Hosting To VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Monitoring_Load_Testing_And_When_To_Upgrade\"><span class=\"toc_number toc_depth_1\">7<\/span> Monitoring, Load Testing And When To Upgrade<\/a><ul><li><a href=\"#Key_Metrics_To_Watch\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Key Metrics To Watch<\/a><\/li><li><a href=\"#Load_Testing_Before_Big_Campaigns\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Load Testing Before Big Campaigns<\/a><\/li><li><a href=\"#Clear_Signals_It_Is_Time_To_Scale_Up_Or_Out\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Clear Signals It Is Time To Scale Up Or Out<\/a><\/li><\/ul><\/li><li><a href=\"#Wrapping_Up_Putting_It_All_Together_On_dchostcom\"><span class=\"toc_number toc_depth_1\">8<\/span> Wrapping Up: Putting It All Together On dchost.com<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Magento_vs_PrestaShop_Resource_Profile_And_Hosting_Basics\">Magento vs PrestaShop: Resource Profile And Hosting Basics<\/span><\/h2>\n<p>Before touching any config file, it helps to understand how Magento and PrestaShop spend CPU and RAM, and where the bottlenecks usually appear.<\/p>\n<h3><span id=\"How_Magento_Uses_Server_Resources\">How Magento Uses Server Resources<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li><strong>High CPU usage<\/strong> per request, especially on category and search pages.<\/li>\n<li><strong>Significant RAM usage<\/strong> per PHP-FPM worker, often 256\u2013512 MB per process when extensions and custom modules are loaded.<\/li>\n<li><strong>Intensive MySQL queries<\/strong>, particularly on product listing, layered navigation and checkout steps.<\/li>\n<li><strong>Heavy use of caches<\/strong> (block, full page, config) where Redis is strongly recommended.<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/magento-icin-en-iyi-hosting-secimi-cpu-ram-nvme-ve-redis-rehberi\/'>CPU, RAM, NVMe and Redis requirements<\/a>, we consistently see CPU and disk IOPS as the first bottlenecks on underpowered servers.<\/p>\n<h3><span id=\"How_PrestaShop_Uses_Server_Resources\">How PrestaShop Uses Server Resources<\/span><\/h3>\n<p>PrestaShop is generally lighter than Magento, but high-traffic stores with many modules can still hit resource limits. Typical characteristics:<\/p>\n<ul>\n<li><strong>Moderate CPU usage<\/strong> per request, but sensitive to bad modules or unoptimized themes.<\/li>\n<li><strong>Lower memory footprint<\/strong> than Magento per PHP worker, but can still reach 256 MB or more on complex stores.<\/li>\n<li><strong>Database load<\/strong> dominated by product listing, cart operations and stats\/logs tables if not cleaned.<\/li>\n<li><strong>Cache<\/strong> can be file based, Memcached or Redis depending on version and configuration.<\/li>\n<\/ul>\n<p>We have already covered platform-specific tuning in our dedicated <a href='https:\/\/www.dchost.com\/blog\/en\/prestashop-hosting-rehberi-php-mysql-onbellek-ve-cdn-ayarlari\/'>PrestaShop hosting guide for PHP, MySQL, caching and CDN<\/a>. In this article we focus on cross-platform hosting decisions: CPU, RAM and database settings that help both Magento and PrestaShop at scale.<\/p>\n<h3><span id=\"When_Shared_Hosting_Is_Not_Enough\">When Shared Hosting Is Not Enough<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>Admin panel is slow during product import or mass price updates.<\/li>\n<li>Checkout sometimes returns 502\/504 errors at busy times.<\/li>\n<li>Hosting control panel shows CPU or IO usage staying at or near 100% for long periods.<\/li>\n<li>You cannot adjust critical settings like innodb_buffer_pool_size or PHP-FPM pool limits.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"CPU_and_RAM_Sizing_For_High-Traffic_Magento_And_PrestaShop\">CPU and RAM Sizing For High-Traffic Magento And PrestaShop<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Baseline_Sizing_By_Traffic_Level\">Baseline Sizing By Traffic Level<\/span><\/h3>\n<p>Think in terms of <strong>concurrent users<\/strong> (visitors actively loading pages at the same time), not only monthly pageviews.<\/p>\n<ul>\n<li><strong>Small \/ new store<\/strong> (up to ~10 concurrent users, a few orders per hour):<br \/>\n    Magento: 2 vCPU, 4\u20136 GB RAM<br \/>\n    PrestaShop: 2 vCPU, 4 GB RAM\n  <\/li>\n<li><strong>Growing store<\/strong> (~30\u201380 concurrent users, 50\u2013300 orders\/day):<br \/>\n    Magento: 4\u20136 vCPU, 8\u201316 GB RAM<br \/>\n    PrestaShop: 4 vCPU, 8\u201312 GB RAM\n  <\/li>\n<li><strong>High-traffic store<\/strong> (100+ concurrent users, 300\u20132000 orders\/day):<br \/>\n    Magento: 8\u201316 vCPU, 16\u201332 GB RAM<br \/>\n    PrestaShop: 6\u201312 vCPU, 16\u201324 GB RAM\n  <\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/woocommerce-icin-ayri-veritabani-ve-onbellek-sunucusu-ne-zaman-mantikli\/'>when a separate database and cache server becomes logical<\/a>.<\/p>\n<h3><span id=\"CPU_Why_Single-Core_Speed_Matters\">CPU: Why Single-Core Speed Matters<\/span><\/h3>\n<p>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:<\/p>\n<ul>\n<li>Prefer <strong>fewer, faster cores<\/strong> over many very slow cores.<\/li>\n<li>Watch <strong>CPU steal time<\/strong> on VPS (e.g. via top or htop). If steal time is high, change plan or node.<\/li>\n<li>Monitor <strong>load average vs core count<\/strong>. Sustained load higher than 1x\u20131.5x number of vCPUs usually means you are CPU bound.<\/li>\n<\/ul>\n<p>We go deeper into selecting vCPU counts for PHP workloads in our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-blog-woocommerce-ve-saas-icin-kac-cpu-ne-kadar-ram\/'>how many vCPUs and how much RAM you really need<\/a>; the same logic applies to Magento and PrestaShop.<\/p>\n<h3><span id=\"RAM_Room_For_PHP_MySQL_And_Cache\">RAM: Room For PHP, MySQL And Cache<\/span><\/h3>\n<p>RAM requirements come from three main consumers:<\/p>\n<ul>\n<li><strong>PHP-FPM workers<\/strong> (Magento workers can easily hit 300\u2013400 MB each; PrestaShop a bit less).<\/li>\n<li><strong>MySQL\/MariaDB<\/strong> buffer pool and caches.<\/li>\n<li><strong>Redis\/Memcached<\/strong> for application and session caching.<\/li>\n<\/ul>\n<p>To size RAM, do a quick back-of-the-envelope calculation:<\/p>\n<ol>\n<li>Estimate realistic <strong>max PHP-FPM workers<\/strong> (we will calculate this in the PHP section).<\/li>\n<li>Multiply workers by estimated memory per worker (e.g. 300 MB for Magento, 200 MB for PrestaShop).<\/li>\n<li>Add MySQL memory (usually 25\u201340% of total RAM on a single-server setup).<\/li>\n<li>Add Redis\/Memcached (usually 512 MB to several GB depending on catalog size).<\/li>\n<li>Leave at least 10\u201320% RAM free for OS and filesystem cache.<\/li>\n<\/ol>\n<p>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.<\/p>\n<h2><span id=\"PHP_And_PHP-FPM_Settings_For_Magento_And_PrestaShop\">PHP And PHP-FPM Settings For Magento And PrestaShop<\/span><\/h2>\n<p>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\u2011commerce.<\/p>\n<h3><span id=\"Key_phpini_Values_For_HighTraffic_Stores\">Key php.ini Values For High\u2011Traffic Stores<\/span><\/h3>\n<p>These values are good starting points for a mid-sized store (adjust upwards for larger setups):<\/p>\n<ul>\n<li><strong>memory_limit<\/strong><br \/>\n    Magento: 512M\u2013768M<br \/>\n    PrestaShop: 256M\u2013512M<br \/>\n    Use higher values for CLI tasks like reindex and bulk import.\n  <\/li>\n<li><strong>max_execution_time<\/strong><br \/>\n    Web requests: 60\u201390 seconds (longer risks leaving stuck PHP workers).<br \/>\n    CLI (php -d max_execution_time=0) for long running tasks like indexing.\n  <\/li>\n<li><strong>max_input_time<\/strong>: 60\u2013120 seconds, especially if you have large forms or imports.<\/li>\n<li><strong>post_max_size<\/strong>: 32M\u2013128M, depending on your largest admin uploads.<\/li>\n<li><strong>upload_max_filesize<\/strong>: 32M\u2013128M (do not set lower than post_max_size).<\/li>\n<li><strong>realpath_cache_size<\/strong>: 256K\u2013512K; Magento benefits from higher values due to many files.<\/li>\n<\/ul>\n<p>We explain these settings in more generic detail in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/php-ayarlarini-dogru-yapmak-memory_limit-max_execution_time-ve-upload_max_filesize-kac-olmali\/'>choosing the right memory_limit, max_execution_time and upload_max_filesize<\/a>. 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.<\/p>\n<h3><span id=\"OPcache_Critical_For_Magento_And_Helpful_For_PrestaShop\">OPcache: Critical For Magento And Helpful For PrestaShop<\/span><\/h3>\n<p>For both platforms, <strong>OPcache must be enabled<\/strong>. Without it, PHP will compile Magento&#8217;s code on every request, which is a non-starter under load.<\/p>\n<p>Good baseline OPcache configuration for a mid-sized store:<\/p>\n<ul>\n<li>opcache.enable = 1<\/li>\n<li>opcache.memory_consumption = 256<\/li>\n<li>opcache.interned_strings_buffer = 16<\/li>\n<li>opcache.max_accelerated_files = 20000\u201340000<\/li>\n<li>opcache.validate_timestamps = 1 (0 in highly controlled environments + manual cache clear)<\/li>\n<li>opcache.revalidate_freq = 60<\/li>\n<\/ul>\n<p>Larger Magento installations may need 512 MB or more of OPcache memory. We discuss these parameters in more detail in our guide to <a href='https:\/\/www.dchost.com\/blog\/en\/php-opcache-ayarlari-wordpress-laravel-ve-woocommerce-icin-en-iyi-konfigurasyon-rehberi\/'>PHP OPcache settings and best configurations<\/a>; you can apply the same principles to both Magento and PrestaShop.<\/p>\n<h3><span id=\"PHP-FPM_Pool_Settings_pm_pmmax_children_And_Friends\">PHP-FPM Pool Settings: pm, pm.max_children And Friends<\/span><\/h3>\n<p>PHP-FPM controls how many PHP workers can run concurrently. This is where you marry your RAM sizing with concurrency needs.<\/p>\n<ul>\n<li><strong>pm<\/strong>: Use dynamic for most setups. Static only if you know exactly how many workers you want.<\/li>\n<li><strong>pm.max_children<\/strong>: The most critical setting. A practical way to calculate:<br \/>\n    pm.max_children = (RAM_for_PHP \/ average_worker_memory)<br \/>\n    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.\n  <\/li>\n<li><strong>pm.start_servers<\/strong>: 20\u201330% of pm.max_children.<\/li>\n<li><strong>pm.min_spare_servers<\/strong>: 20\u201330% of pm.max_children.<\/li>\n<li><strong>pm.max_spare_servers<\/strong>: 50\u201360% of pm.max_children.<\/li>\n<li><strong>pm.max_requests<\/strong>: 300\u2013500 (recycle workers to mitigate memory leaks).<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>If you are new to PHP-FPM pool tuning, our article on <a href='https:\/\/www.dchost.com\/blog\/en\/wordpress-ve-woocommerce-icin-php-fpm-ayarlari-pm-pm-max_children-ve-pm-max_requests-hesaplama-rehberi\/'>PHP-FPM settings and calculating pm.max_children and pm.max_requests<\/a> for WordPress and WooCommerce provides a very similar step-by-step method you can reuse here.<\/p>\n<h2><span id=\"MySQL_MariaDB_Settings_For_Busy_Magento_And_PrestaShop_Stores\">MySQL \/ MariaDB Settings For Busy Magento And PrestaShop Stores<\/span><\/h2>\n<p>Many e\u2011commerce 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.<\/p>\n<h3><span id=\"InnoDB_Buffer_Pool_Size_The_Big_Lever\">InnoDB Buffer Pool Size: The Big Lever<\/span><\/h3>\n<p>Magento and PrestaShop should run on InnoDB only. The <strong>innodb_buffer_pool_size<\/strong> determines how much data and indexes can be cached in RAM.<\/p>\n<ul>\n<li>On a <strong>dedicated database server<\/strong>, set buffer pool to 60\u201370% of total RAM.<\/li>\n<li>On a <strong>single server<\/strong> with web + DB, 25\u201340% of RAM is more realistic; the rest is needed for PHP, Redis and OS.<\/li>\n<\/ul>\n<p>Example: A single 16 GB server running both web and DB services:<\/p>\n<ul>\n<li>8 GB for PHP-FPM + OPcache.<\/li>\n<li>4 GB for InnoDB buffer pool.<\/li>\n<li>1\u20132 GB for Redis\/Memcached.<\/li>\n<li>2\u20133 GB for OS and filesystem cache.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Other_Important_InnoDB_Settings\">Other Important InnoDB Settings<\/span><\/h3>\n<p>Beyond buffer pool, a few parameters consistently help e\u2011commerce workloads:<\/p>\n<ul>\n<li><strong>innodb_log_file_size<\/strong>: 512M\u20131G per log file for medium to large stores. Too small causes frequent flushes and IO spikes.<\/li>\n<li><strong>innodb_log_buffer_size<\/strong>: 64M\u2013256M, higher if you have many concurrent writes.<\/li>\n<li><strong>innodb_flush_log_at_trx_commit<\/strong>: Values:<br \/>\n    1 = safest, most disk IO (log flushed every transaction).<br \/>\n    2 = safer performance trade-off (log written every transaction, flushed every second).<br \/>\n    Many stores use 2 on NVMe storage, accepting a small risk window to gain better write performance.<\/li>\n<li><strong>innodb_flush_method<\/strong>: O_DIRECT (or O_DIRECT_NO_FSYNC) to reduce double buffering on Linux.<\/li>\n<li><strong>innodb_file_per_table<\/strong>: 1 (should be enabled on modern installations).<\/li>\n<\/ul>\n<p>We discuss these patterns and slow query analysis in depth for WooCommerce in our article on <a href='https:\/\/www.dchost.com\/blog\/en\/woocommerce-icin-mysql-innodb-tuning-kontrol-listesi-buffer-pool-indeksleme-ve-slow-query-analizi-nasil-akillica-yapilir\/'>MySQL\/InnoDB tuning checklists<\/a>; the same queries (catalog, cart, orders) are similar on Magento and PrestaShop.<\/p>\n<h3><span id=\"Connection_Temp_Table_And_Query_Cache_Settings\">Connection, Temp Table And Query Cache Settings<\/span><\/h3>\n<ul>\n<li><strong>max_connections<\/strong>: Do not just set a huge number. Start with 150\u2013300 and monitor. Too many connections + insufficient RAM = swapping and collapse.<\/li>\n<li><strong>tmp_table_size<\/strong> and <strong>max_heap_table_size<\/strong>: Set both equal, e.g. 64M\u2013256M. When too low, many queries spill to disk.<\/li>\n<li><strong>query_cache_type<\/strong> = 0 and <strong>query_cache_size<\/strong> = 0 on modern MySQL; query cache is deprecated\/removed and hurts scaling.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h2><span id=\"Cache_Sessions_And_Background_Jobs\">Cache, Sessions And Background Jobs<\/span><\/h2>\n<p>CPU, RAM, PHP and MySQL tuning get you far, but high-traffic e\u2011commerce really shines when cache and background processing are used correctly.<\/p>\n<h3><span id=\"Application_Cache_Redis_Or_Memcached\">Application Cache: Redis Or Memcached<\/span><\/h3>\n<p>For Magento, <strong>Redis is the standard choice<\/strong> for:<\/p>\n<ul>\n<li>Full page cache.<\/li>\n<li>Default\/metadata cache.<\/li>\n<li>Sessions (optional but recommended).<\/li>\n<\/ul>\n<p>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.<\/p>\n<p>On a combined server, dedicate 512M\u20134G 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.<\/p>\n<h3><span id=\"PHP_Sessions_Avoid_File_Storage_At_Scale\">PHP Sessions: Avoid File Storage At Scale<\/span><\/h3>\n<p>File-based PHP sessions work on small sites, but for busy stores they cause disk IO and lock contention. Better options:<\/p>\n<ul>\n<li><strong>Redis<\/strong> for sessions: fast, centralized, can scale out later.<\/li>\n<li><strong>Memcached<\/strong> for sessions: also fast but no persistence (sessions lost if it restarts).<\/li>\n<\/ul>\n<p>We explain pros and cons of each approach in our platform-agnostic guide to <a href='https:\/\/www.dchost.com\/blog\/en\/php-session-ve-cache-depolamasini-dogru-secmek-dosya-redis-ve-memcachedin-wordpress-ve-laravel-performansina-etkisi\/'>choosing PHP session and cache storage between files, Redis and Memcached<\/a>; the same trade-offs apply one-to-one to Magento and PrestaShop.<\/p>\n<h3><span id=\"Cron_And_Background_Jobs\">Cron And Background Jobs<\/span><\/h3>\n<p>Both Magento and PrestaShop rely on cron for important tasks:<\/p>\n<ul>\n<li>Reindexing and cache warm-up.<\/li>\n<li>Abandoned cart emails, newsletters and marketing automations.<\/li>\n<li>Order status updates, stock sync with ERPs or marketplaces.<\/li>\n<\/ul>\n<p>On high-traffic servers:<\/p>\n<ul>\n<li>Run cron via <strong>system cron<\/strong>, not via web hits.<\/li>\n<li>Schedule resource-heavy jobs (reindex, big imports) outside absolute peak hours.<\/li>\n<li>On larger setups, consider a separate worker server for heavy background tasks so they do not compete with frontend traffic.<\/li>\n<\/ul>\n<h2><span id=\"Practical_Sizing_Scenarios_For_Magento_And_PrestaShop\">Practical Sizing Scenarios For Magento And PrestaShop<\/span><\/h2>\n<p>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.<\/p>\n<h3><span id=\"Scenario_1_Medium_PrestaShop_Store_With_Campaign_Spikes\">Scenario 1: Medium PrestaShop Store With Campaign Spikes<\/span><\/h3>\n<p>Profile:<\/p>\n<ul>\n<li>20\u201350 concurrent users at peak.<\/li>\n<li>3000+ products.<\/li>\n<li>Up to 300 orders\/day during campaigns.<\/li>\n<\/ul>\n<p>Recommended single-server starting point:<\/p>\n<ul>\n<li><strong>6 vCPU, 12\u201316 GB RAM, NVMe SSD<\/strong>.<\/li>\n<li>PHP-FPM: pm.dynamic, pm.max_children ~30 (estimate 220 MB per worker, ~6.5 GB used at peak), pm.max_requests = 400.<\/li>\n<li>php.ini: memory_limit = 512M, max_execution_time = 60, upload_max_filesize = 64M.<\/li>\n<li>OPcache: 256 MB memory, 20000\u201330000 max_accelerated_files.<\/li>\n<li>MySQL: innodb_buffer_pool_size ~4 GB, innodb_log_file_size 512M, tmp_table_size\/max_heap_table_size 128M.<\/li>\n<li>Redis: 1 GB for cache + sessions.<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Scenario_2_Busy_Magento_Store_With_Heavy_Extensions\">Scenario 2: Busy Magento Store With Heavy Extensions<\/span><\/h3>\n<p>Profile:<\/p>\n<ul>\n<li>80\u2013150 concurrent users.<\/li>\n<li>10000+ products, complex pricing rules and custom modules.<\/li>\n<li>1000+ orders\/day during big events.<\/li>\n<\/ul>\n<p>Recommended architecture:<\/p>\n<ul>\n<li><strong>Application VPS\/dedicated<\/strong>: 12\u201316 vCPU, 24\u201332 GB RAM, NVMe SSD.<\/li>\n<li><strong>Database VPS\/dedicated<\/strong>: 8\u201312 vCPU, 32 GB RAM, NVMe SSD, tuned for MySQL\/MariaDB.<\/li>\n<\/ul>\n<p>Application server settings:<\/p>\n<ul>\n<li>PHP-FPM: pm.dynamic, pm.max_children 50\u201370 (estimate 350 MB per worker, ~24 GB RAM reserved), pm.max_requests 400.<\/li>\n<li>php.ini: memory_limit 768M for web, 1024M for CLI reindex; max_execution_time 90.<\/li>\n<li>OPcache: 512 MB, 40000 max_accelerated_files.<\/li>\n<li>Redis: 2\u20134 GB for cache + sessions, separate instances\/DBs per purpose.<\/li>\n<\/ul>\n<p>Database server settings:<\/p>\n<ul>\n<li>innodb_buffer_pool_size ~20\u201324 GB.<\/li>\n<li>innodb_log_file_size 1G, innodb_flush_log_at_trx_commit = 1 or 2 depending on risk tolerance.<\/li>\n<li>tmp_table_size\/max_heap_table_size 256M+<\/li>\n<li>max_connections 300\u2013400 (backed by enough RAM to handle it).<\/li>\n<\/ul>\n<p>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.<\/p>\n<h3><span id=\"Scenario_3_Growing_Store_Migrating_From_Shared_Hosting_To_VPS\">Scenario 3: Growing Store Migrating From Shared Hosting To VPS<\/span><\/h3>\n<p>Profile:<\/p>\n<ul>\n<li>Magento or PrestaShop store currently on shared hosting.<\/li>\n<li>Frequent 503 \/ 504 errors during campaigns.<\/li>\n<li>Cannot edit MySQL or PHP-FPM settings.<\/li>\n<\/ul>\n<p>Typical migration step at dchost.com:<\/p>\n<ul>\n<li>Move to a <strong>4\u20136 vCPU, 8\u201312 GB RAM VPS with NVMe<\/strong>.<\/li>\n<li>Enable OPcache and configure PHP-FPM pools as described above.<\/li>\n<li>Tune MySQL buffer pool and temp table sizes.<\/li>\n<li>Move sessions and application cache to Redis.<\/li>\n<li>Set up proper cron jobs and disable any web-based cron triggers.<\/li>\n<\/ul>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingden-vpse-sorunsuz-gecis-rehberi\/'>moving from shared hosting to a VPS without downtime<\/a> walks through the DNS and cutover side in detail.<\/p>\n<h2><span id=\"Monitoring_Load_Testing_And_When_To_Upgrade\">Monitoring, Load Testing And When To Upgrade<\/span><\/h2>\n<p>All these settings are starting points. The real confirmation comes from watching the server under real traffic and scheduled load tests.<\/p>\n<h3><span id=\"Key_Metrics_To_Watch\">Key Metrics To Watch<\/span><\/h3>\n<ul>\n<li><strong>CPU usage<\/strong>: Aim for sustained averages below 70% at peak. Short spikes are fine.<\/li>\n<li><strong>RAM and swap<\/strong>: Swapping under load is a red flag; consider adding RAM or reducing PHP workers.<\/li>\n<li><strong>Disk IOwait<\/strong>: Long waits often indicate undersized MySQL buffer pool or slow disk.<\/li>\n<li><strong>MySQL slow query log<\/strong>: Focus on catalog, cart and checkout queries; add indexes or rewrite problematic queries.<\/li>\n<li><strong>PHP-FPM status<\/strong>: Maxed out workers (all busy) means request queueing and increasing response times.<\/li>\n<\/ul>\n<h3><span id=\"Load_Testing_Before_Big_Campaigns\">Load Testing Before Big Campaigns<\/span><\/h3>\n<p>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 <a href='https:\/\/www.dchost.com\/blog\/en\/trafik-patlamasindan-once-load-test-yapmak-k6-jmeter-ve-locust-ile-kapasite-olcme-rehberi\/'>load testing your hosting before traffic spikes<\/a>. Apply it to your Magento or PrestaShop store with realistic user flows and ramp-up patterns.<\/p>\n<h3><span id=\"Clear_Signals_It_Is_Time_To_Scale_Up_Or_Out\">Clear Signals It Is Time To Scale Up Or Out<\/span><\/h3>\n<ul>\n<li>CPU and RAM are persistently near capacity despite reasonable tuning.<\/li>\n<li>MySQL slow query log keeps growing even after indexing and buffer pool tuning.<\/li>\n<li>PHP-FPM frequently hits pm.max_children and logs slow requests.<\/li>\n<li>Checkout latency grows significantly faster than catalog page latency under load.<\/li>\n<\/ul>\n<p>At that point, options include:<\/p>\n<ul>\n<li>Upgrading to more vCPUs\/RAM on the same VPS or dedicated server.<\/li>\n<li>Splitting application and database onto separate servers.<\/li>\n<li>Adding dedicated servers or additional VPS instances behind a load balancer.<\/li>\n<\/ul>\n<h2><span id=\"Wrapping_Up_Putting_It_All_Together_On_dchostcom\">Wrapping Up: Putting It All Together On dchost.com<\/span><\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4678,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4677","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4677","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4677"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4677\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4678"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4677"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4677"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4677"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}