The Laravel cache can bring speed improvements to your web application. I compare the speed of each Laravel cache driver to see which is the best for performance.

If you’re looking to improve the performance of your Laravel web application, then implementing a cache layer could be a good option. As a very high-level overview, using a cache allows data to be stored and then quickly retrieved. Common use cases include replacing slow or repetitive database queries, or even entire HTTP responses.

Although Laravel comes with a great, easy to use solution for server-side caching, there is still a lot to consider when implementing a cache layer in your application. What should be cached? How long should it be cached for? Where should we cache it?

The answer to all of those questions is usually «it depends on your circumstances», however we’re going to tackle the last one. The Laravel cache service offers multiple cache «drivers», allowing different back-end storage engines to be used. When choosing which one is best to use, it is again likely to depend on your circumstances.

Do you need a cache that is quick and easy to setup / maintain? Where should the cache store be hosted? Should it be available to multiple servers? Is performance the ultimate priority? Performance is what I’ll be focusing on.

Cache drivers: APC vs Database vs File vs Memcached vs Redis

The cache drivers we will be focusing on are those that come with the default Laravel installation:

  • APC (APCu)
  • Database (this cache driver uses Laravel’s database engine, which is again driver based — we’ll be using two — MySQL & SQLite)
  • File
  • Memcached
  • Redis

Laravel also comes with two other drivers that I won’t be testing:

  • Array (data is stored in memory for the current PHP process (e.g. a HTTP request, running an Artisan command) so wouldn’t be suitable for most people, it’s mainly used for tests).
  • DynamoDB (an AWS proprietary NoSQL key-value based database, which you’re only likely to use if you host all of your infrastructure on AWS)

Testing Laravel cache drivers

I’ll be testing the read and write speed of each cache driver with 5 different types of commonly cached data:

  • Integer — a single number
  • Stats — a JSON encoded string of 100 numbers
  • Paragraph — a text string of 150 words
  • Article — a text string of 2500 words
  • Webpage — an entire HTML webpage (I’ve used the webpage for the most popular BBC news article at the time of writing)

I’ve written an Artisan command (available on GitHub) in a default Laravel 6 installation to make 1,000 reads and 1,000 writes for each of the above data types. For each test, the time taken to complete the action will be recorded in microseconds. This will then be used to calculate an average time for both reading and writing for each data type, for each cache driver.

As for server environment, I’ll be testing on the lowest spec VPS available from Linode (1GB RAM / 1 CPU) that has been freshly provisioned by Laravel Forge, using the default configuration that it provides for PHP 7.3. There will be minimal load on the server as there will be no inbound HTTP traffic and only the default services running.

Laravel cache driver speed tests

APC cache driver

Integer 0.770 2.416
Stats 0.679 2.367
Paragraph 0.631 2.128
Article 0.676 2.433
Webpage 0.694 2.120

Database (MySQL) cache driver

Integer 642.146 390.471
Stats 714.820 412.997
Paragraph 811.301 383.895
Article 1151.277 412.056
Webpage 3643.461 765.362

Database (SQLite) cache driver

Integer 1432.321 137.590
Stats 1353.896 137.828
Paragraph 1132.085 161.893
Article 1194.738 173.334
Webpage 2159.022 253.023

File cache driver

Integer 147.066 33.503
Stats 132.957 35.460
Paragraph 153.218 35.498
Article 158.506 46.110
Webpage 395.767 165.265

Memcached cache driver

Integer 63.500 35.403
Stats 63.671 38.796
Paragraph 63.031 37.054
Article 138.603 74.496
Webpage 1125.189 842.751

Redis cache driver

Integer 57.925 54.762
Stats 55.013 54.390
Paragraph 60.338 56.676
Article 44035.899 78.775
Webpage 1192.044 378.57

Performance observations

From looking at the above results, it’s clear that the APC drivers is by far the fastest Laravel cache driver in our tests with speeds far better than any of the others. There was little difference in the timings between the smaller and larger datasets.

Next up, the two memory based cache stores Memcached and Redis both produced similar results — although the write speeds were slightly better in Memcached and the read speeds were slightly better in Redis. You may have noticed the rather high read speed for the «article» data in Redis. Having tried slightly different amounts of data and different servers in different data centres, this anomaly still occurred.

The Laravel file cache driver came out in third place, with speeds roughly double those achieved with Redis and Memcached.

The second slowest Laravel cache driver appears to be the database driver connected to a MySQL (5.7) database, with the speeds being roughly 5 times slower than those achieved with Redis and Memcached.

Finally, the slowest cache driver in our tests was the  the database driver connected to SQLite (a flat file based database) — the speeds appear to be approximately 10 times slower than those achieved with Redis and Memcached.

So, which Laravel cache driver should I use?

As I mentioned in the start of this article, the answer is probably «it depends».

APC obviously gave the best results by far, however it can only be used by a single PHP process. So if you need you cached data to be accessed via HTTP requests and CLI, or even across multiple servers, you won’t be able to use it. For simple, single server Laravel applications, it is probably your best choice.

If you don’t mind a little extra server maintenance (having to install & maintain additional services), the memory based cache drivers Memcached and Redis are great options. A server provisioning tool like Laravel Forge with make the initial setup easier, and a fully managed hosted service will greatly reduce the amount of additional maintenance. If you’ll be caching large amounts of data, many server providers offer high memory instances.

Whilst the the file based driver is incredibly easy to setup and offers OK speeds, you may run into problems with disk IO if your application will have high activity levels. It might be a good choice to start with, but you’ll likely need to replace it with a different cache store if your application sees an increase in traffic.

Finally, we come to the database cache drivers. Again, they are a good option if you want a quick and easy solution as you’re likely already running a database. If top-level performance is the priority, these won’t be the answer for you as they tend to be the slowest, and will require other server resources — such as CPU usage for MySQL.

In conclusion

There is so much to consider when implementing a cache layer, and whilst better performance is likely to be your priority, you’ll need to do further research, or even better, your own testing to get the best results.

You can find my test script here:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Любишь мемасики?

Подпишись на мой телеграм-канал!