Software recommendations

We recommend using the following software for production instances of Magento:

• PHP
• Nginx and PHP-FPM
• MySQL
• Varnish cache
• (Magento Commerce only) Use the Elasticsearch & Elasticsearch Search Adapter

For multi-server deployments, or for merchants planning on scaling their business, we recommend the following:

• Redis for sessions (from 2.0.6+)
• A separate Redis instance as your default cache (do not use this instance for page cache)

See Magento 2.2.x technology stack requirements for information about supported versions of each type of software.

Operating system

Operating system configurations and optimizations are similar for Magento as other high-load web applications. As the number of concurrent connections handled by the server increases, the number of available sockets can become fully allocated. The Linux kernel supports a mechanism to “reuse” and “recycle” TCP connections. Be aware that more aggressive recycling than re-use may cause issues on the load balancers. To enable these kernel settings, set the following values in /etc/sysctl.conf: 

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

The kernel parameter net.core.somaxconn controls the maximum number of open sockets waiting for connections. This value can be safely increased to 1024, but it should be correlated with the ability of the server to handle this amount. To enable this kernel parameter, set the following value in /etc/sysctl.conf: 

net.core.somaxconn = 1024

PHP

Magento fully supports PHP 7.1. There are several factors to account for when configuring PHP to get maximum speed and efficiency on requests processing.

PHP extensions

We recommend limiting the list of active PHP extensions to those that are required for Magento functionality:

• php-bcmath
• php-cli
• php-common
• php-gd
• php-intl
• php-mbstring
• php-mcrypt
• php-opcache
• php-pdo
• php-soap
• php-xml

Adding more extensions increases library load times.

PHP Settings

To guarantee successful execution of all Magento instances without dumping data or code to disk, set the memory limit as follows:

memory_limit=768MB

ByteCode

To get maximum speed out of Magento 2 on PHP7, you must activate the OpCache module and properly configure it. These settings are recommended for the module:

  opcache.memory_consumption=512MB
  opcache.max_accelerated_files=60000
  opcache.consistency_checks=0
  opcache.validate_timestamps=0
  opcache.enable_cli=1

When you fine-tune the memory allocation for opcache, take into account the size of Magento’s code base and all your extensions. Magento’s performance team uses the values in the preceding example for testing because it provides enough space in opcache for the average number of installed extensions.

If you have a low-memory machine and you do not have many extensions or customizations installed, use the following settings to get a similar result:

opcache.memory_consumption=64
opcache.max_accelerated_files=60000

Web server

Magento fully supports the Nginx and Apache web servers. Magento provides sample recommended configuration files in the <magento_home>/nginx.conf.sample (Nginx) and <magento_home>.htaccess.sample (Apache) files. The Nginx sample contains settings for better performance and is designed so that little reconfiguration is required. Some of the main configuration best practices defined in the sample file include:

• Settings for caching static content in a browser
• Memory and execution time settings for PHP
• Content compression settings

You should also configure the number of threads for input request processing, as listed below:

MySQL

This document does not provide in-depth MySQL tuning instructions because each store and environment is different, but we can make some general recommendations.

There have been many improvements to MySQL 5.6 and 5.7. We are confident that MySQL is distributed with good default settings. The most critical settings are:

Varnish

Magento highly recommends using Varnish as the full page cache server for your store. The PageCache module is still present in the codebase, but it should be used for development purposes only. It should not be used together with, or instead of, Varnish.

Install Varnish on a separate server in front of the web tier. It should accept all incoming requests and provide cached page copies. To allow Varnish to work effectively with secured pages, an SSL termination proxy can be placed in front of Varnish. Nginx can be used for this purpose.

Magento distributes a sample configuration file for Varnish (versions 4 and 5) that contains all recommended settings for performance. Among them the most critical in terms of performance are:

• Backend health check polls the Magento server to determine whether it is responding in a timely manner.
• Grace mode allows you to instruct Varnish to keep an object in cache beyond its Time to Live (TTL) period and serve this stale content if Magento is not healthy or if fresh content hasn’t been fetched yet.
• Saint mode blacklists unhealthy Magento servers for a configurable amount of time. As a result, unhealthy backends cannot serve traffic when using Varnish as a load balancer.

See Advanced Varnish configuration for more information about implementing these features.

Optimize asset performance

In general, we recommend storing your assets (images, JS, CSS, etc) on a CDN for optimal performance.

If your site does not require deploying a large number of locales and your servers are in the same region as the majority of your customers, you may find significant performance gains at a lower cost by storing your assets in Varnish instead of using a CDN.

To store your assets in Varnish, add the following VCL entries in your default.vcl file generated by Magento for Varnish 5.

At the end of the if statement for PURGE requests in the vcl_recv subroutine, add:

# static files are cacheable. remove SSL flag and cookie
if (req.url ~ "^/(pub/)?(media|static)/.*\.(ico|html|css|js|jpg|jpeg|png|gif|tiff|bmp|mp3|ogg|svg|swf|woff|woff2|eot|ttf|otf)$") {
  unset req.http.Https;
  unset req.http./*  */;
  unset req.http.Cookie;
}

In the vcl_backend_response subroutine, look for the if statement that unsets the cookie for GET or HEAD requests. The updated if block should look like the following:

# validate if we need to cache it and prevent from setting cookie
# images, css and js are cacheable by default so we have to remove cookie also
if (beresp.ttl > 0s && (bereq.method == "GET" || bereq.method == "HEAD")) {
  unset beresp.http.set-cookie;
if (bereq.url !~ "\.(ico|css|js|jpg|jpeg|png|gif|tiff|bmp|gz|tgz|bz2|tbz|mp3|ogg|svg|swf|woff|woff2|eot|ttf|otf)(\?|$)") {
  set beresp.http.Pragma = "no-cache";
  set beresp.http.Expires = "-1";
  set beresp.http.Cache-Control = "no-store, no-cache, must-revalidate, max-age=0";
  }
}

Restart the Varnish server to flush cached assets whenever you upgrade your site or deploy/update assets.

Cacheing and session servers

Magento provides a number of options to store your cache and session data, including Redis, Memcache, filesystem, and database. Some of these options are discussed below.

Single web node setup

If you plan to serve all your traffic with just one web node, it does not make sense to put your cache on a remote Redis server. Instead, either use the filesystem or a local Redis server. If you want to use the filesystem, put your cache folders on a volume mounted on a RAM filesystem. If you want to use a local Redis server, we highly recommend configuring Redis so it uses sockets for direct connections, rather than exchange data through HTTP.

Multiple web nodes setup

For a multiple web nodes setup, Redis is the best option. Because Magento actively caches lots of data for better performance, pay attention to your network channel between the web nodes and the Redis server. You do not want the channel to become a bottleneck for request processing.