Because speed is an important aspect of e-commerce thirty bees has included several different levels of caching systems in the core. The caching systems not only reduce each individual page load time, but they also increase the mount of load your server can handle since requests are served from the cache. But how can you actually quantify what the caching system does and how each one affects your site as a whole? There is a fairly solid way, load testing a site, you can see how each cache system will affect your site’s load time.

For these tests we are using a Cloudways 2GB Vultr server, with PHP 7.1 as the PHP version and Maria DB 10.0 as the database software version. To generate the load I am using a Digital Ocean instance with Locust.io as the load engine. The actual testing parameters will be one request to the index page, a request to the category page, a request to a product page, and a search. So a fairly simple test that will test most all systems of the shop. For the load it will start at 1 user and add 1 user every second. So we do not totally lock the server up I am stopping the tests when the response from the server reaches 10 seconds. At that point a site is virtually not usable. For all tests I am suing a CDN with the site, the reason for using the CDN is as the tests advance, the port can get saturated and cause slow downs because the server’s traffic ability is exceeded.

 

Test with all caches off

thirty bees no cache

As you can see, this was a pretty quick test. The server could only hold about 74 concurrent users before the requests started taking over 10 seconds.

Cache on Force Compile

Next I tested with the cache settings below.

cache settings force compile

Here are the results from that test.

thirty bees force compile

As you can see the test results were pretty similar because we are recompiling all of the templates.

Caches on – MYSQL Cache

For the next tests I have used these settings in the back office.

cache settings changes

The results that these settings produced were easily visible from the other settings. The site could hold over 100 more users concurrently before the server started taking over 10 seconds to respond to page requests.

thirty bees caches on

 

Cache on Never Recompile templates

Next I tested with the never recompile templates set to on, this should give us an indication of how much overhead this feature uses in checking the templates. The settings below were used.

cache never recompile

Here are the results of the test, it seems to have added 5 more users to the capacity of the site. This means that our template checking is not using too many resources, but it is using some, a decent trade off for the feature in my opinion.

thirty bees never recompile templates

 

Caches on File System

For the next test, I changed from using the MySQL cache to using the file system cache. I used the settings below.

Cache File System

This test was actually produced surprising results for me. Because of the way the template files are cached, it increased the over all load capacity of the site by almost 100 people, ending up at 270 users before the requests took over 10 seconds.

thirty bees file cache

 

Server Side Caches

These caches might be a little misleading in their naming. What they actually cache is user data on the server side. Since this test is not creating user accounts or user data, they really are not needed for this test. But, they are required to use the full page caching. So we are going to use APCu cache and set the full page caching system to enabled, with the default settings set.

 

Full Page Cache

The full page cache is where thirty bees really shines and sheds the load. This cache caches whole pages into memory allowing them to be retrieved quickly, not only lowering page load time, but also increasing the number of active users on your site. Below you can see how well this test did.

thirty bees all caches

If you look at the time at the end of the test, it might look a little misleading because the other tests were until 10 seconds of request time. This test was the same as well, but at the end when the server failed it jumped from 6.5 seconds to 21 seconds in a single jump. So I would scale the 563 number back a little, maybe to 550 users. That is still twice as many users as the test without using the full page cache.

 

Conclusion

thirty bees has many different caching methods. so work better in certain scenarios than others. The point of this test was to illustrate how the different caching methods operated under real world loads, not just single page loads like if you are testing in Pingdom or GT Metrix. These tests were based off of stability with a large amount of users. Running different modules, different themes, and on different servers, your milage may vary.