{"id":3239,"date":"2025-12-08T23:43:40","date_gmt":"2025-12-08T20:43:40","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/website-slow-only-at-certain-hours-diagnose-cpu-io-and-mysql-issues\/"},"modified":"2025-12-08T23:43:40","modified_gmt":"2025-12-08T20:43:40","slug":"website-slow-only-at-certain-hours-diagnose-cpu-io-and-mysql-issues","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/website-slow-only-at-certain-hours-diagnose-cpu-io-and-mysql-issues\/","title":{"rendered":"Website Slow Only at Certain Hours? Diagnose CPU, IO and MySQL Issues"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Noticing that your website is fast most of the day, but becomes painfully slow at specific hours? This pattern is rarely random. In real hosting environments, time-based slowdowns almost always point to resource bottlenecks: saturated CPU, overloaded disk IO, or a MySQL database that struggles under peak load. The challenge is separating guesswork (&#8220;our hosting is bad&#8221;) from data (&#8220;CPU is 100% every night between 20:00\u201322:00&#8221; or &#8220;IOwait spikes during backup windows&#8221;).<\/p>\n<p>In this article, we\u2019ll walk through how we at dchost.com typically approach these cases on both shared hosting and <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> servers. You\u2019ll learn how to recognize whether your bottleneck is CPU, disk IO or MySQL, which tools and panels to look at, and what to change in your application or hosting plan. We\u2019ll stay practical: concrete metrics, screenshots you can imagine from cPanel and SSH, and a checklist you can follow next time your site slows down at the same hour again.<\/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=\"#Why_Your_Website_Is_Only_Slow_at_Certain_Hours\"><span class=\"toc_number toc_depth_1\">1<\/span> Why Your Website Is Only Slow at Certain Hours<\/a><\/li><li><a href=\"#Step_1_Confirm_the_Slowdown_Pattern_with_Real_Measurements\"><span class=\"toc_number toc_depth_1\">2<\/span> Step 1 \u2013 Confirm the Slowdown Pattern with Real Measurements<\/a><ul><li><a href=\"#Use_proper_speed_test_tools_at_different_hours\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Use proper speed test tools at different hours<\/a><\/li><li><a href=\"#Correlate_slow_times_with_your_business_and_tasks\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Correlate slow times with your business and tasks<\/a><\/li><\/ul><\/li><li><a href=\"#Step_2_Check_CPU_and_PHP_Bottlenecks_on_Shared_Hosting_and_VPS\"><span class=\"toc_number toc_depth_1\">3<\/span> Step 2 \u2013 Check CPU and PHP Bottlenecks on Shared Hosting and VPS<\/a><ul><li><a href=\"#On_shared_hosting_read_your_control_panel_resource_graphs\"><span class=\"toc_number toc_depth_2\">3.1<\/span> On shared hosting: read your control panel resource graphs<\/a><\/li><li><a href=\"#On_a_VPS_use_SSH_tools_like_tophtop\"><span class=\"toc_number toc_depth_2\">3.2<\/span> On a VPS: use SSH tools like top\/htop<\/a><\/li><li><a href=\"#What_CPU_saturation_usually_looks_like_from_the_website\"><span class=\"toc_number toc_depth_2\">3.3<\/span> What CPU saturation usually looks like from the website<\/a><\/li><li><a href=\"#Quick_CPU-related_mitigations_on_shared_hosting\"><span class=\"toc_number toc_depth_2\">3.4<\/span> Quick CPU-related mitigations on shared hosting<\/a><\/li><li><a href=\"#Quick_CPU_mitigations_on_a_VPS\"><span class=\"toc_number toc_depth_2\">3.5<\/span> Quick CPU mitigations on a VPS<\/a><\/li><\/ul><\/li><li><a href=\"#Step_3_Detect_Disk_IO_IOwait_and_Storage_Bottlenecks\"><span class=\"toc_number toc_depth_1\">4<\/span> Step 3 \u2013 Detect Disk IO (IOwait) and Storage Bottlenecks<\/a><ul><li><a href=\"#On_shared_hosting_IO_graphs_and_backup_windows\"><span class=\"toc_number toc_depth_2\">4.1<\/span> On shared hosting: IO graphs and backup windows<\/a><\/li><li><a href=\"#On_a_VPS_check_IOwait_and_disk_activity\"><span class=\"toc_number toc_depth_2\">4.2<\/span> On a VPS: check IOwait and disk activity<\/a><\/li><li><a href=\"#Fixing_IO-related_slowdowns\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Fixing IO-related slowdowns<\/a><\/li><\/ul><\/li><li><a href=\"#Step_4_Investigate_MySQLMariaDB_Bottlenecks\"><span class=\"toc_number toc_depth_1\">5<\/span> Step 4 \u2013 Investigate MySQL\/MariaDB Bottlenecks<\/a><ul><li><a href=\"#Symptoms_of_a_database_bottleneck\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Symptoms of a database bottleneck<\/a><\/li><li><a href=\"#On_shared_hosting_what_you_can_see\"><span class=\"toc_number toc_depth_2\">5.2<\/span> On shared hosting: what you can see<\/a><\/li><li><a href=\"#On_a_VPS_use_the_slow_query_log_and_basic_MySQL_metrics\"><span class=\"toc_number toc_depth_2\">5.3<\/span> On a VPS: use the slow query log and basic MySQL metrics<\/a><\/li><li><a href=\"#Database-related_fixes_that_reduce_peak-hour_slowdowns\"><span class=\"toc_number toc_depth_2\">5.4<\/span> Database-related fixes that reduce peak-hour slowdowns<\/a><\/li><\/ul><\/li><li><a href=\"#Step_5_Look_Beyond_the_Server_Traffic_Spikes_Bots_and_External_Services\"><span class=\"toc_number toc_depth_1\">6<\/span> Step 5 \u2013 Look Beyond the Server: Traffic Spikes, Bots and External Services<\/a><ul><li><a href=\"#Legitimate_traffic_peaks_vs_abusive_traffic\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Legitimate traffic peaks vs. abusive traffic<\/a><\/li><li><a href=\"#Third-party_APIs_and_services\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Third-party APIs and services<\/a><\/li><\/ul><\/li><li><a href=\"#Step_6_When_Its_Time_to_Scale_Up_or_Change_Architecture\"><span class=\"toc_number toc_depth_1\">7<\/span> Step 6 \u2013 When It\u2019s Time to Scale Up or Change Architecture<\/a><ul><li><a href=\"#Signs_your_current_plan_is_simply_too_small\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Signs your current plan is simply too small<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Troubleshooting_Checklist_for_Time-Based_Slowdowns\"><span class=\"toc_number toc_depth_1\">8<\/span> Practical Troubleshooting Checklist for Time-Based Slowdowns<\/a><\/li><li><a href=\"#Bringing_It_All_Together_and_How_dchostcom_Can_Help\"><span class=\"toc_number toc_depth_1\">9<\/span> Bringing It All Together (and How dchost.com Can Help)<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_Your_Website_Is_Only_Slow_at_Certain_Hours\">Why Your Website Is Only Slow at Certain Hours<\/span><\/h2>\n<p>When a website is consistently slow 24\/7, causes are usually structural: underpowered hosting, heavy code, missing caching, large images, or poor database design. When the site is fast most of the day but slow at clearly defined periods, you are almost always seeing a <strong>time-bound resource contention<\/strong> problem.<\/p>\n<p>Common real-world patterns we see:<\/p>\n<ul>\n<li><strong>Peak visitor traffic<\/strong>: Lunch or evening peaks where CPU and MySQL connections spike simultaneously.<\/li>\n<li><strong>Shared hosting \u201cneighbor noise\u201d<\/strong>: Other accounts on the same server run backups, imports or cron jobs at predictable times.<\/li>\n<li><strong>Your own scheduled tasks<\/strong>: WordPress\/WooCommerce crons, report generation, feeds, or synchronizations stacked at the same minute every hour.<\/li>\n<li><strong>Backup and antivirus windows<\/strong>: Full-server backups and malware scans stressing disk IO and CPU for 30\u201360 minutes.<\/li>\n<li><strong>External systems<\/strong>: Payment gateways, shipping APIs or CRM integrations that respond slowly under their own peak load.<\/li>\n<\/ul>\n<p>To fix the issue properly, you need to answer three questions:<\/p>\n<ol>\n<li><strong>Exactly when<\/strong> is the site slow?<\/li>\n<li><strong>Which resource<\/strong> hits its limit at those times (CPU, IO, MySQL, memory, connections)?<\/li>\n<li><strong>What workload<\/strong> is causing that spike (visitors, bots, backups, crons, imports)?<\/li>\n<\/ol>\n<p>Once you map the timing to a resource and a workload, the right solution (optimize, spread out tasks, cache better, or upgrade) becomes much clearer.<\/p>\n<h2><span id=\"Step_1_Confirm_the_Slowdown_Pattern_with_Real_Measurements\">Step 1 \u2013 Confirm the Slowdown Pattern with Real Measurements<\/span><\/h2>\n<p>Before jumping into server metrics, confirm the pattern from the browser side. Time-based slowdowns can easily be masked by caching, or misinterpreted if you only test occasionally.<\/p>\n<h3><span id=\"Use_proper_speed_test_tools_at_different_hours\">Use proper speed test tools at different hours<\/span><\/h3>\n<p>Run tests at different times of the day from tools such as GTmetrix, PageSpeed Insights or WebPageTest. We explain how to interpret these tools in detail in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-sitenizin-hizini-dogru-olcmek-gtmetrix-pagespeed-insights-ve-webpagetest-rehberi\/\">how to properly test your website speed<\/a>.<\/p>\n<p>Track at least:<\/p>\n<ul>\n<li><strong>TTFB (Time To First Byte)<\/strong> \u2013 server response time. If this spikes only during slow hours, the issue is server-side.<\/li>\n<li><strong>Fully loaded time<\/strong> \u2013 how long until all assets are loaded.<\/li>\n<li><strong>Number of requests<\/strong> \u2013 whether your page weight changes or it\u2019s purely a server capacity issue.<\/li>\n<\/ul>\n<p>If front-end assets and total size are similar but TTFB jumps from, say, 200 ms to 2\u20133 seconds in peak hours, you are most likely facing CPU\/IO\/MySQL constraints. You can also dive deeper into server-side causes in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yuksek-ttfb-sorununu-cozmek-wordpress-ve-php-sitelerde-sunucu-tarafli-nedenler-ve-cozumler\/\">fixing high TTFB on WordPress and PHP sites<\/a>.<\/p>\n<h3><span id=\"Correlate_slow_times_with_your_business_and_tasks\">Correlate slow times with your business and tasks<\/span><\/h3>\n<p>Make a simple timeline:<\/p>\n<ul>\n<li>When do visitors usually peak? (analytics)<\/li>\n<li>When do you run imports, exports, feed generation or reports?<\/li>\n<li>When do your email campaigns land in inboxes and drive traffic?<\/li>\n<li>When are your backup jobs scheduled (site or external tools)?<\/li>\n<\/ul>\n<p>Write down these time ranges and compare them with observed slow periods. This makes the next steps (checking hosting and VPS metrics) much more meaningful.<\/p>\n<h2><span id=\"Step_2_Check_CPU_and_PHP_Bottlenecks_on_Shared_Hosting_and_VPS\">Step 2 \u2013 Check CPU and PHP Bottlenecks on Shared Hosting and VPS<\/span><\/h2>\n<p>CPU is the first place we look when a website slows down at defined hours. On PHP-based sites (WordPress, WooCommerce, Laravel, custom PHP) every request involves PHP, and PHP is CPU-heavy under load.<\/p>\n<h3><span id=\"On_shared_hosting_read_your_control_panel_resource_graphs\">On shared hosting: read your control panel resource graphs<\/span><\/h3>\n<p>If you use cPanel or a similar panel, your account usually has a \u201cResource Usage\u201d or \u201cCPU and Concurrent Connections\u201d section. We\u2019ve explained those graphs in detail in our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/cpanelde-kaynak-limitleri-cpu-io-ep-ram-ve-resource-limit-reached-hatasi\/\">understanding cPanel resource limits and the \u2018Resource Limit Reached\u2019 error<\/a>.<\/p>\n<p>During or right after a slowdown, open that page and look for:<\/p>\n<ul>\n<li><strong>CPU usage<\/strong> \u2013 is it flatlining near 100% of your allocated limit?<\/li>\n<li><strong>Entry Processes (EP)<\/strong> \u2013 number of concurrent processes. If this hits the limit, new requests queue or get 503 errors.<\/li>\n<li><strong>Physical memory (RAM)<\/strong> \u2013 high RAM + high CPU suggests PHP is working very hard.<\/li>\n<li><strong>Faults \/ \u201cResource limit reached\u201d events<\/strong> \u2013 clear indicator you\u2019re hitting caps during that hour.<\/li>\n<\/ul>\n<p>If the graphs show CPU or EP pegged exactly during your slow hours and normal otherwise, you\u2019ve found a strong candidate: CPU saturation at peak.<\/p>\n<h3><span id=\"On_a_VPS_use_SSH_tools_like_tophtop\">On a VPS: use SSH tools like top\/htop<\/span><\/h3>\n<p>On a VPS or <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>, log in via SSH and run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">top\n<\/code><\/pre>\n<p>or, if installed,<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">htop\n<\/code><\/pre>\n<p>Key things to look at <strong>while the slowdown is happening<\/strong>:<\/p>\n<ul>\n<li><strong>Overall CPU usage<\/strong> \u2013 is it consistently above 80\u201390%?<\/li>\n<li><strong>Per-core usage<\/strong> \u2013 one core at 100% can bottleneck even if others are idle (common with PHP-FPM misconfiguration).<\/li>\n<li><strong>Top CPU-consuming processes<\/strong> \u2013 typically php-fpm, lsphp, Apache\/nginx workers, or MySQL.<\/li>\n<\/ul>\n<p>If PHP-FPM is your web engine, you can tune its process limits. We covered this in-depth for WordPress\/WooCommerce in our guide 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 (pm, pm.max_children, pm.max_requests)<\/a>. The principles are the same for most PHP apps: too few workers cause queues and high TTFB, too many cause CPU and memory exhaustion.<\/p>\n<h3><span id=\"What_CPU_saturation_usually_looks_like_from_the_website\">What CPU saturation usually looks like from the website<\/span><\/h3>\n<p>Typical browser-side symptoms of CPU issues in peak hours:<\/p>\n<ul>\n<li>Initial page response (TTFB) is slow, but once HTML arrives, static assets load quickly.<\/li>\n<li>Admin pages (e.g. WordPress dashboard) are much slower than cached front pages.<\/li>\n<li>Intermittent 503 or 508 errors during stress while the rest of the day is fine.<\/li>\n<\/ul>\n<h3><span id=\"Quick_CPU-related_mitigations_on_shared_hosting\">Quick CPU-related mitigations on shared hosting<\/span><\/h3>\n<p>On a shared plan, you cannot directly add more CPU cores, but you can reduce peak CPU usage:<\/p>\n<ul>\n<li><strong>Enable and configure caching<\/strong>: For WordPress, use a full-page cache plugin or LiteSpeed Cache if your host supports it.<\/li>\n<li><strong>Disable or limit heavy plugins<\/strong>: Page builders, analytics, security scanners, related posts and visual sliders can be expensive.<\/li>\n<li><strong>Offload cron jobs<\/strong>: Disable WP-Cron and run a real cron at a lower frequency, as described in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpresste-wp-cron-devre-disi-birakma-ve-gercek-cron-job-kurulumu\/\">using real cron jobs instead of wp-cron<\/a>.<\/li>\n<li><strong>Optimize PHP limits<\/strong>: Avoid excessively high <code>memory_limit<\/code> or <code>max_execution_time<\/code> that let slow scripts run forever. We have a dedicated 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 PHP memory_limit and execution time<\/a>.<\/li>\n<\/ul>\n<p>If you frequently hit CPU or EP caps despite optimizations, it may be time to upgrade your shared plan or move to a VPS. We discuss server-side signals in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/hosting-paketinizi-yukseltmeniz-gerektigini-gosteren-9-sunucu-tarafli-sinyal\/\">9 hosting upgrade signals based on server metrics<\/a>.<\/p>\n<h3><span id=\"Quick_CPU_mitigations_on_a_VPS\">Quick CPU mitigations on a VPS<\/span><\/h3>\n<ul>\n<li><strong>Tune PHP-FPM workers<\/strong> to match CPU and RAM.<\/li>\n<li><strong>Enable OPcache<\/strong> so PHP doesn\u2019t recompile scripts on every request.<\/li>\n<li><strong>Add a reverse proxy cache<\/strong> such as nginx fastcgi_cache or LiteSpeed full-page caching for dynamic sites.<\/li>\n<li><strong>Review cron schedule<\/strong> and spread heavy jobs across off-peak minutes instead of running them all at 00:00.<\/li>\n<\/ul>\n<h2><span id=\"Step_3_Detect_Disk_IO_IOwait_and_Storage_Bottlenecks\">Step 3 \u2013 Detect Disk IO (IOwait) and Storage Bottlenecks<\/span><\/h2>\n<p>Even if CPU looks fine, your server can be blocked waiting for disk operations: reading PHP files, database data, logs, or backups. This appears as high <strong>IOwait<\/strong> and sluggish performance especially under heavy writes (backups, imports).<\/p>\n<h3><span id=\"On_shared_hosting_IO_graphs_and_backup_windows\">On shared hosting: IO graphs and backup windows<\/span><\/h3>\n<p>In cPanel-like dashboards, you\u2019ll often see an <strong>IO Usage<\/strong> or <strong>Disk IO<\/strong> graph for your account. Look for:<\/p>\n<ul>\n<li>Spikes in IO usage (near your limit) during the exact time your website becomes slow.<\/li>\n<li>\u201cResource limit reached\u201d events mentioning IO or faults tagged as I\/O-related.<\/li>\n<\/ul>\n<p>Some time-based IO slowdowns are caused by <strong>server-wide tasks<\/strong> like backups and malware scans. These may not show under your own account\u2019s IO metrics, but you\u2019ll notice that slowdowns always coincide with a specific time window (e.g., 02:00\u201302:20 every night). In that case:<\/p>\n<ul>\n<li>Ask support whether full-server backups or scans run in that window.<\/li>\n<li>If yes, see whether schedules can be shifted, or if your account can be moved to a less busy node.<\/li>\n<\/ul>\n<p>On our shared infrastructure at dchost.com, we plan backup windows and IO budgets carefully, but for IO-heavy sites (e.g. large WooCommerce stores), we still often recommend moving to NVMe VPS plans so you have guaranteed disk performance.<\/p>\n<h3><span id=\"On_a_VPS_check_IOwait_and_disk_activity\">On a VPS: check IOwait and disk activity<\/span><\/h3>\n<p>On Linux, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">top\n<\/code><\/pre>\n<p>and look at the CPU line. The <code>wa<\/code> value is IOwait: the percentage of time the CPU is idle but waiting for disk.<\/p>\n<ul>\n<li>If <code>wa<\/code> is consistently high (e.g. &gt; 20%) during slow hours while overall CPU is not maxed, you likely have a disk bottleneck.<\/li>\n<\/ul>\n<p>Then use tools like:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">iostat -x 1 10\nvmstat 1 10\niotop -o<\/code><\/pre>\n<p>to see which devices and processes are hitting disk hardest. Typical culprits:<\/p>\n<ul>\n<li>Database server flushing large InnoDB buffers or rewriting indexes.<\/li>\n<li>Backup tools reading the entire filesystem.<\/li>\n<li>Log files growing very quickly (debug logging enabled in production).<\/li>\n<li>Image or video processing jobs.<\/li>\n<\/ul>\n<h3><span id=\"Fixing_IO-related_slowdowns\">Fixing IO-related slowdowns<\/span><\/h3>\n<p>Depending on what you find, options include:<\/p>\n<ul>\n<li><strong>Reduce write amplification<\/strong>: Turn off verbose debug logging on production; rotate logs; avoid writing massive temporary files.<\/li>\n<li><strong>Reschedule backups<\/strong> to truly off-peak hours, and ensure incremental backups are used where possible.<\/li>\n<li><strong>Move heavy processing jobs off the web server<\/strong> (e.g. media conversions to a worker VPS).<\/li>\n<li><strong>Upgrade storage<\/strong> to faster disks (NVMe over SATA) or move to a plan with higher IOPS limits.<\/li>\n<\/ul>\n<p>If you\u2019re setting up or benchmarking a new VPS, we also recommend simple IO tests during non-peak and peak periods. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/yeni-vps-aldiginizda-ilk-yapmaniz-gerekenler-cpu-disk-ve-ag-performansini-benchmark-ile-test-etmek\/\">benchmarking CPU, disk and network performance on a new VPS<\/a> walks through practical commands you can reuse later when diagnosing slowdowns.<\/p>\n<h2><span id=\"Step_4_Investigate_MySQLMariaDB_Bottlenecks\">Step 4 \u2013 Investigate MySQL\/MariaDB Bottlenecks<\/span><\/h2>\n<p>For database-backed sites (WordPress, PrestaShop, Magento, custom apps), MySQL\/MariaDB is often the real bottleneck behind time-based slowdowns. As traffic grows and data accumulates, queries that were fine at launch become slow.<\/p>\n<h3><span id=\"Symptoms_of_a_database_bottleneck\">Symptoms of a database bottleneck<\/span><\/h3>\n<p>From the user\u2019s perspective, MySQL issues look similar to CPU problems, but there are subtle clues:<\/p>\n<ul>\n<li>The whole site (including cached pages) seems fine, but specific actions become slow: search, filtering, cart\/checkout, dashboards.<\/li>\n<li>Some pages with many queries (e.g. product listing with multiple filters) are much slower in peak hours than in the morning.<\/li>\n<li>Short bursts of database errors or timeouts, especially under concurrent users.<\/li>\n<\/ul>\n<h3><span id=\"On_shared_hosting_what_you_can_see\">On shared hosting: what you can see<\/span><\/h3>\n<p>On shared hosting, you usually have limited access to MySQL internals, but you can still:<\/p>\n<ul>\n<li>Look for <strong>MySQL-related errors<\/strong> in your application logs (e.g. &#8220;too many connections&#8221;, lock wait timeouts).<\/li>\n<li>Use plugins or admin tools to <strong>measure number of queries<\/strong> per page and detect very slow queries.<\/li>\n<li>Ask support whether the <strong>database server load<\/strong> correlates with your slow periods.<\/li>\n<\/ul>\n<p>For WooCommerce and other busy stores, we\u2019ve seen many sites hit limits not because of raw CPU, but because of unoptimized queries. 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\/\">WooCommerce MySQL\/InnoDB tuning<\/a> shows what we look at in practice; most concepts apply to other PHP apps as well.<\/p>\n<h3><span id=\"On_a_VPS_use_the_slow_query_log_and_basic_MySQL_metrics\">On a VPS: use the slow query log and basic MySQL metrics<\/span><\/h3>\n<p>On a VPS with root or MySQL access, enable the slow query log:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">SET GLOBAL slow_query_log = 1;\nSET GLOBAL long_query_time = 1;  -- or 0.5 for finer detail\n<\/code><\/pre>\n<p>Then, during or after slow hours, inspect the log (often <code>\/var\/log\/mysql\/slow.log<\/code> or similar) to see:<\/p>\n<ul>\n<li>Which queries are taking &gt; 1 second.<\/li>\n<li>Which tables are frequently scanned without indexes.<\/li>\n<li>Whether specific pages or modules cause repeated slow queries.<\/li>\n<\/ul>\n<p>You can also run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">SHOW PROCESSLIST;\n<\/code><\/pre>\n<p>to see live queries during peak. If many connections are stuck in &#8220;Locked&#8221; or &#8220;Copying to tmp table&#8221; states, or the number of concurrent connections grows until MySQL refuses new ones, you have a clear database bottleneck.<\/p>\n<h3><span id=\"Database-related_fixes_that_reduce_peak-hour_slowdowns\">Database-related fixes that reduce peak-hour slowdowns<\/span><\/h3>\n<ul>\n<li><strong>Optimize slow queries<\/strong>: Add missing indexes, rewrite suboptimal SQL, or adjust ORM-generated queries to reduce joins and sorts.<\/li>\n<li><strong>Use caching layers<\/strong>: Object caches (Redis\/Memcached) and full-page caching dramatically cut database load for repeated page views.<\/li>\n<li><strong>Clean up bloat<\/strong>: Old sessions, transient options, logs and revisions can slow down queries that scan large tables.<\/li>\n<li><strong>Increase MySQL resources<\/strong>: On a VPS, tune <code>innodb_buffer_pool_size<\/code>, <code>max_connections<\/code>, and related settings so MySQL can keep more data in memory and handle concurrency better.<\/li>\n<li><strong>Split heavy reporting<\/strong>: Run big reports or exports on a replicated database or at off-peak hours, not during your main sales window.<\/li>\n<\/ul>\n<p>When MySQL becomes the dominant bottleneck and simple tuning is not enough, separating the database from the web server or scaling vertically\/clustered may be necessary. We discuss such architectures in our guides on <a href=\"https:\/\/www.dchost.com\/blog\/en\/veritabani-sunucusunu-uygulama-sunucusundan-ayirmak-ne-zaman-mantikli\/\">when to separate database and application servers<\/a> and on high-availability database setups.<\/p>\n<h2><span id=\"Step_5_Look_Beyond_the_Server_Traffic_Spikes_Bots_and_External_Services\">Step 5 \u2013 Look Beyond the Server: Traffic Spikes, Bots and External Services<\/span><\/h2>\n<p>Not every time-based slowdown is purely internal. Some are triggered by patterns in traffic or third-party services.<\/p>\n<h3><span id=\"Legitimate_traffic_peaks_vs_abusive_traffic\">Legitimate traffic peaks vs. abusive traffic<\/span><\/h3>\n<p>Use your analytics and server logs to see what\u2019s happening during slow hours:<\/p>\n<ul>\n<li><strong>Are page views or concurrent users significantly higher?<\/strong> That\u2019s healthy growth, and your infrastructure must be sized accordingly.<\/li>\n<li><strong>Are specific countries, IP ranges or user agents spiking?<\/strong> Could be bots, scrapers or even early-stage DDoS attempts.<\/li>\n<\/ul>\n<p>If you suspect bots are overloading your site at certain hours (e.g. aggressive crawlers after you publish news), rate limiting and WAF rules can help. We\u2019ve shared practical WAF strategies in our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/waf-ve-bot-korumasi-cloudflare-modsecurity-ve-fail2bani-ayni-masada-baristirmanin-sicacik-hikayesi\/\">combining WAF and bot protection on real hosting stacks<\/a>.<\/p>\n<h3><span id=\"Third-party_APIs_and_services\">Third-party APIs and services<\/span><\/h3>\n<p>Some slowness originates outside your hosting:<\/p>\n<ul>\n<li>Payment gateways that respond slowly during local business peak hours.<\/li>\n<li>Shipping and ERP APIs that get overloaded when many merchants sync inventory at the same time.<\/li>\n<li>External marketing and personalization scripts added to the page.<\/li>\n<\/ul>\n<p>To diagnose this, compare:<\/p>\n<ul>\n<li>Server-side TTFB (from speed tools or browser dev tools Network tab) \u2013 if this is fine but the page still feels slow, external scripts may be the culprit.<\/li>\n<li>Application logs \u2013 measure how long API calls take and add timeouts or fallbacks.<\/li>\n<\/ul>\n<p>In general, do not block your entire page render waiting for slow third-party services. Use asynchronous loading on the front-end, and on the back-end, use reasonable timeouts and background jobs where possible.<\/p>\n<h2><span id=\"Step_6_When_Its_Time_to_Scale_Up_or_Change_Architecture\">Step 6 \u2013 When It\u2019s Time to Scale Up or Change Architecture<\/span><\/h2>\n<p>After you\u2019ve optimized code, caching, cron schedules, and database queries, you might still see CPU, IO or MySQL hitting hard limits during predictable peaks. At that point, the question is not \u201cWhat\u2019s broken?\u201d but \u201cIs this plan still sufficient for our traffic and business?\u201d<\/p>\n<h3><span id=\"Signs_your_current_plan_is_simply_too_small\">Signs your current plan is simply too small<\/span><\/h3>\n<ul>\n<li>Resource graphs consistently show CPU or IO usage near the limit during your normal, expected peak hours.<\/li>\n<li>Even well-optimized pages and queries are slower in peak traffic compared to off-peak.<\/li>\n<li>You\u2019ve implemented caching correctly, but logins, carts and checkouts still struggle with modest concurrency.<\/li>\n<\/ul>\n<p>In those cases, options with dchost.com typically include:<\/p>\n<ul>\n<li><strong>Upgrading shared hosting<\/strong> to a plan with more CPU\/IO allowance for small\/medium sites.<\/li>\n<li><strong>Moving to an NVMe VPS<\/strong> for dedicated CPU, RAM and high IOPS disk, ideal for growing e-commerce or SaaS apps.<\/li>\n<li><strong>Planning dedicated or clustered setups<\/strong> for high-traffic stores, news sites or mission-critical applications.<\/li>\n<\/ul>\n<p>We also recommend monitoring and alerting on your VPS so that you can see trends before they turn into outages. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-izleme-ve-alarm-kurulumu-prometheus-grafana-ve-uptime-kuma-ile-baslangic\/\">VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma<\/a> is a good starting point if you manage your own servers.<\/p>\n<h2><span id=\"Practical_Troubleshooting_Checklist_for_Time-Based_Slowdowns\">Practical Troubleshooting Checklist for Time-Based Slowdowns<\/span><\/h2>\n<p>Here is a concise, repeatable checklist you can follow next time your site is slow only at certain hours:<\/p>\n<ol>\n<li><strong>Record the time window<\/strong>\n<ul>\n<li>Note exact start\/end times when the site feels slow.<\/li>\n<li>Check if this repeats daily\/weekly or aligns with marketing campaigns.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Measure from the outside<\/strong>\n<ul>\n<li>Run speed tests (TTFB, fully loaded time) during slow and normal hours.<\/li>\n<li>Use dev tools to see if TTFB or front-end assets are the main issue.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Check hosting panel metrics<\/strong> (shared hosting)\n<ul>\n<li>CPU, IO, EP, RAM graphs for the exact slow period.<\/li>\n<li>Any \u201cResource limit reached\u201d errors (CPU\/IO\/EP).<\/li>\n<\/ul>\n<\/li>\n<li><strong>Check server metrics<\/strong> (VPS\/dedicated)\n<ul>\n<li><code>top\/htop<\/code> for CPU, IOwait, per-process usage.<\/li>\n<li><code>iostat<\/code> and <code>iotop<\/code> for disk-intensive tasks.<\/li>\n<li>MySQL status and slow query log for database hotspots.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Correlate with workloads<\/strong>\n<ul>\n<li>Cron jobs (WordPress cron, imports, reports).<\/li>\n<li>Backups, security scans, cache warmups.<\/li>\n<li>Traffic spikes, bots, external API calls.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Apply targeted fixes<\/strong>\n<ul>\n<li>Enable\/strengthen caching and reduce heavy plugins.<\/li>\n<li>Spread out cron jobs and backup tasks.<\/li>\n<li>Optimize the worst database queries and add indexes.<\/li>\n<li>Rate limit abusive traffic and tune WAF rules.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Re-test and re-monitor<\/strong>\n<ul>\n<li>Repeat speed tests and review metrics in the next peak window.<\/li>\n<li>If you still hit hard limits despite optimizations, plan a resource upgrade.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>If you are on shared hosting and frequently see \u201cresource limit reached\u201d, our dedicated article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/paylasimli-hostingde-resource-limit-reached-hatasini-onlemek\/\">avoiding the resource limit reached error on shared hosting<\/a> covers practical steps to stay within your limits without harming performance.<\/p>\n<h2><span id=\"Bringing_It_All_Together_and_How_dchostcom_Can_Help\">Bringing It All Together (and How dchost.com Can Help)<\/span><\/h2>\n<p>When your website is slow only at certain hours, the real goal is to stop guessing. With a bit of structured detective work\u2014timing, external speed tests, control panel graphs, and VPS metrics\u2014you can usually pinpoint whether the bottleneck is CPU, disk IO, MySQL, or something external like bots or APIs. Once that link is clear, the right mix of caching, scheduling changes, query optimization and, where necessary, capacity upgrades becomes straightforward instead of stressful.<\/p>\n<p>At dchost.com, we work with both shared hosting and VPS customers who run into these exact patterns as their traffic and business grow. If you\u2019re not sure whether your issue is configuration, code or simply lack of resources, our team can review your metrics, explain what\u2019s happening in plain language, and suggest a realistic path: from small optimizations on your current plan to moving up to an NVMe VPS or dedicated setup when it\u2019s truly justified. If your site keeps slowing down at the same times every day, that\u2019s your infrastructure asking for attention\u2014reach out, share your observations, and we\u2019ll help you turn those noisy peak hours back into calm, predictable performance.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Noticing that your website is fast most of the day, but becomes painfully slow at specific hours? This pattern is rarely random. In real hosting environments, time-based slowdowns almost always point to resource bottlenecks: saturated CPU, overloaded disk IO, or a MySQL database that struggles under peak load. The challenge is separating guesswork (&#8220;our hosting [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":3240,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-3239","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\/3239","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=3239"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/3239\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/3240"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=3239"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=3239"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=3239"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}