Hey to Amasty blog readers!
Today we are going to talk about Magento 2 site performance. Pages load speed is not the thing we need to explain to anyone. It’s enough to recall the latest case you got angry when the favorite store wouldn’t load the desired product page. Do you think your customers should have okayed that?
Then it’s time to seek a new solution!
As you know, caching is one of the mightest mechanisms to let your customers get what they want faster without spending priceless time on waiting for pages to load. Magento 2 supports several caching solutions.
In this post, we are to consider the pros and cons of all the solutions and find out how they work.
What is a Cache Backend?
Put simply, this is the place where the cached information is stored. So, your site performance is directly affected by the cache backend you utilize. We’ll try to make a short overview of the existing Magento 2 cache backend solutions to help you make the choice that suits your store needs.
Solution #1: File system
How does it work?
The cached data is stored in files on an disk. You can find them on a server in the magento_installation_folder/var/cache/ and magento_installation_folder/var/page_cache/ folders.
The load speed depends on the disk reading/writing speed. So, a proper file system and SSD storage can improve the results.
The solution is available out of the box. So, there is no need to deal with the configuration.
You can flush the cache with server access details only by removing all files from the var/cache/ and var/page_cache/ folders. So, there is no need to log into the Admin Panel.
The disk reading/writing speed is usually slower than the speed of the same operations for database or RAM.
A shared server or a server with several stores can run out of inodes. Most hosters use filesystems with inodes limit – a number files/folder allowed for creation/uploading. So when a device is out of inodes new files can’t be created or uploaded, even if there is free space on the disk.
Solution #2: Database
How does it work?
This not very popular (from our experience) solution uses Magento 2 database to store cached data. The new records are created in the cache and cache_tag tables with every new visited page.
So, in this case, you should pay attention to a wisely chosen management system and a proper database configuration.
The solution is scalable. In case a store is replicated on several servers in order to balance site load, the database can be used as a common cache storage for numerous Magento nodes.
Moreover, it does not require any special skills for enabling it. All you need is to edit the only file on the server by following the guide from Magento team.
It is also possible to flush the cache without accessing the Admin Panel by truncating the cache and cache_tag tables. However, you’ll need to have the database credentials.
Due to several common issues, this solution is not fully compatible with custom cache types. (Read more about it here.) However, if only a native Magento 2 caching functionality is used, these issues will not affect your store anyhow.
A number of records in the related tables grow really fast. If there are several websites/stores in a Magento instance, it can reach 10 million in a few hours and cause huge database server load. This will inevitably affect the site performance.
Solution #3: Redis
How does it work?
Redis is one of the most popular caching mechanisms on the web. It keeps data in the server memory (RAM). In some cases, the cached data can also partially be saved on the disk, however, this feature is almost not used with Magento.
It’s a good idea to consider using a separate server with a proper RAM size for the Redis cache storage.
The memory reading and writing speed is much faster than the same operations performed with the disk or database.
The cached data is stored and handled in an optimized way with the help of cache tags and inner indexation so it takes less time to find the requested information.
The cache storage can be hosted on a separate server, so Magento does not have to share resources with it. This cache backend is scalable both vertically (can handle the growing number of requests, as well as storing more data) and horizontally (can be used as a common caching storage for several replicated Magento installations on separate servers).
There is a possibility to configure the cached data replicating on other servers. So, if the connection with the main storage is lost for some reasons, the data will be taken from the replicated one. This feature is called a Master/Slave replication.
As far as the main storage is a server memory, the size of cached data is limited by the size of a server RAM.
The installation and configuration are not so obvious and it’s better to contact a skilled system administrator.
Solution #4: Varnish
How does it work?
This really mighty and revolutionary solution stores cached data in a memory as well. But the trick is in the way it works. The thing is that it caches the web server responses. So, when data is loaded from the cache, visitors’ requests do not even reach a web server and Magento pages are loaded directly from the Varnish.
As far as this solution is RAM-hungry as well, you need to make sure there is enough memory on the server or you should move Varnish to a separate one.
Requests to pages from site’s visitors are not handled by a web server and Magento. In combination with the usage of the server memory as a storage, this behavior gives sufficient advantage in a speed of returning the cached content.
It is supported natively in Magento 2. So, there is no need to deal with 3rd-party extensions.
Varnish does not support HTTPS (SSL protocol). As a workaround, there is an option to configure an SSL terminator or proxy to decrypt HTTPS traffic from visitors before it reaches Varnish and encrypt the response back.
If all the files from var/cache folder are removed manually, the Varnish service should be restarted.
This solution is not fully compatible with some 3rd-party Magento extensions (e.g.: different GeoIP modules).
The optimal configuration is really tricky and requires specific skills and knowledge.
What does Amasty offer or what is a cache warming?
No matter what cache backend is used, there is a common issue – the very first visitor will see an uncached page. Therefore the loading time will be much slower.
The obvious solution here is to visit these pages to make them cached before a real customer will get to your store. And the best thing is that there is no difference if it’s done by a real person or by a bot.
So, warming is a preliminary crawling of site’s pages fulfilled in order to make them cached. And this is the case Amasty can help you with. Our Full Page Cache Warmer for Magento 2 extension generates a queue of URLs and visits them one by one. So, when you have some visitors on your store they do not have to wait while Magento generates the page from a scratch – it will be loaded from the cache as our module has already visited it before.
That’s a wrap for today. We hope that this article gave you a general understanding of Magento 2 cache storage methods and their pros and cons.
Still have any questions? Leave them in the comments below, and we’ll do our best to help you.