# How to Troubleshoot Common Magento 2 Performance Bottlenecks: A 9-Step Systematic Guide > Troubleshoot Magento 2 performance bottlenecks with our 9-step guide. Optimize Varnish Redis MySQL frontend assets and extensions for faster speeds. - Repository: [Alessandro Ronchi/mageres](https://github.com/aleron75/mageres) - Tags: how-to-guide - Published: 2026-02-24 --- **Systematically troubleshoot Magento 2 performance bottlenecks by establishing baseline metrics with Blackfire profiling, verifying Varnish and Redis cache layers, tuning MySQL `innodb_buffer_pool_size`, optimizing front-end assets with Magepack bundling, and auditing custom extensions for inefficient database queries.** Magento 2 performance degradation typically stems from database overload, cache misconfiguration, or inefficient custom code execution. The **aleron75/mageres** repository curates essential performance tools and configuration references that streamline identifying and resolving these latency sources. This guide translates those community-vetted resources into an actionable troubleshooting workflow based on the repository’s [Performance](https://github.com/aleron75/mageres/blob/master/README.md#performance) section. ## Establish Baseline Metrics and Continuous Monitoring Before modifying configurations, capture current performance data to measure improvement. Use **Blackfire.io**—listed in the *Performance* section of [`README.md`](https://github.com/aleron75/mageres/blob/main/README.md)—to profile page-load times, server-response latency, and MySQL query execution. Run a baseline capture with: ```bash blackfire curl https://your-magento.test > baseline.json ``` For ongoing visibility, configure automated health checks using New Relic or Blackfire agents, and periodically run `bin/magento setup:performance:options:list` to audit system settings against current best practices stored in `resources.csv`. ## Verify Full-Page Cache and Redis Configuration Missing or misconfigured caching forces every request to hit PHP and the database, causing severe latency. First, confirm cache status: ```bash bin/magento cache:status ``` Ensure **Varnish** is active for Full-Page Cache (FPC) and check logs at `var/log/varnish.log`. For session and default caching, verify Redis is configured in [`app/etc/env.php`](https://github.com/aleron75/mageres/blob/main/app/etc/env.php): ```php // app/etc/env.php – Redis configuration for cache and sessions 'cache' => [ 'frontend' => [ 'default' => [ 'backend' => 'Cm_Cache_Backend_Redis', 'backend_options' => [ 'server' => '127.0.0.1', 'port' => '6379', 'database'=> '0', 'compress_data' => true ] ], 'page_cache' => [ 'backend' => 'Cm_Cache_Backend_Redis', 'backend_options' => [ 'server' => '127.0.0.1', 'port' => '6379', 'database'=> '1', 'compress_data' => true ] ] ] ], 'session' => [ 'save' => 'redis', 'redis' => [ 'host' => '127.0.0.1', 'port' => '6379', 'database' => 2, 'disable_locking' => 0, 'max_concurrency' => 6, 'break_after_frontend' => 5, 'break_after_adminhtml' => 30, 'first_lifetime' => 600, 'bot_first_lifetime' => 60, 'bot_lifetime' => 7200, 'disable_locking' => 0 ] ], ``` Redis dramatically reduces database-backed session reads and cache latency compared to file-based storage. ## Optimize Database Configuration and Indexers Poor MySQL tuning causes latency spikes during high-traffic periods. Check `innodb_buffer_pool_size` and allocate 70–80% of available RAM: ```bash mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';" ``` The **aleron75/mageres** repository references a default MySQL configuration file under the *Performance* section that provides recommended baseline settings for Magento 2 workloads. Additionally, stale indexes slow catalog and search queries. Confirm all indexers run on schedule rather than "Update on Save": ```bash bin/magento index:status ``` Verify cron jobs execute every minute via `crontab -l` to ensure indexes remain current and do not trigger expensive full-table scans during customer requests. ## Profile Code and Audit Front-End Assets Custom modules often bypass Magento’s caching layers. Use **Magento 2 DevTools** (referenced in the repository’s *Tools* section) or enable the built-in profiler: ```bash bin/magento dev:debug:profiler:start ``` For front-end bottlenecks, examine JS/CSS bundle sizes. Large assets increase Time-to-First-Byte (TTFB). Install **Magepack**—a tool listed in the repository’s *Performance* section—to bundle and minify assets: ```bash npm i -g @magepack/cli magepack init magepack build ``` This generates optimized files in `pub/static/frontend/Magepack/`, replacing numerous individual module requests with consolidated bundles. ## Isolate Third-Party Extension Impact Poorly written extensions add database queries or event listeners. Temporarily disable non-essential modules to isolate performance drains: ```bash bin/magento module:disable Vendor_Module ``` Re-measure response times with Blackfire after each disablement to identify specific culprits before contacting developers or seeking alternatives. ## Key Files in the Magento 2 Performance Toolkit Understanding these core files accelerates troubleshooting: - **[`README.md`](https://github.com/aleron75/mageres/blob/main/README.md)** (Performance section): Central index of proven tools including Blackfire, Magepack, and MySQL tuning references. - **`resources.csv`**: Source data containing URLs to official performance best-practice documentation. - **[`app/etc/env.php`](https://github.com/aleron75/mageres/blob/main/app/etc/env.php)**: Defines cache backends, session storage, and database connections. - **`bin/magento`**: CLI entry point for cache management, indexing, and profiling commands. - **[`composer.json`](https://github.com/aleron75/mageres/blob/main/composer.json)**: Version constraints; outdated dependencies can introduce hidden inefficiencies. ## Summary - Establish **baseline metrics** using Blackfire before making changes to quantify improvements. - Verify **Varnish FPC** and **Redis** configuration in [`app/etc/env.php`](https://github.com/aleron75/mageres/blob/main/app/etc/env.php) to prevent unnecessary database hits. - Tune **MySQL** `innodb_buffer_pool_size` to 70–80% of RAM and ensure indexers run on schedule via cron. - Use **Magepack** to reduce front-end HTTP requests and bundle assets efficiently. - Isolate **third-party extensions** by temporarily disabling modules to identify code-level bottlenecks. ## Frequently Asked Questions ### How do I check if Redis is properly configured for Magento 2 cache and sessions? Inspect [`app/etc/env.php`](https://github.com/aleron75/mageres/blob/main/app/etc/env.php) for the `Cm_Cache_Backend_Redis` backend configuration under the `cache` array and ensure `session.save` is set to `redis`. Additionally, run `redis-cli monitor` to verify active cache operations, and check that `bin/magento cache:status` shows cache types as enabled. ### What is the recommended innodb_buffer_pool_size for Magento 2? Set `innodb_buffer_pool_size` to 70–80% of your server's total RAM. For an 8 GB server, allocate approximately 5.6–6.4 GB to this buffer. This setting is critical for reducing disk I/O by caching frequently accessed data and indexes in memory. ### How can I identify which custom module is slowing down my Magento 2 store? Temporarily disable suspect modules using `bin/magento module:disable Vendor_Module` and profile the site with Blackfire after each change. Compare response times and database query counts between configurations. Modules adding observers to frequently fired events like `sales_order_save_after` are common culprits. ### When should I use Magepack versus default Magento bundling? Use **Magepack** when you observe high TTFB due to excessive individual JavaScript module requests. Magepack creates optimized bundles across pages (product, category, CMS) more aggressively than default Magento bundling, significantly reducing HTTP request counts for complex storefronts.