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
TEST
READ
WRITE
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
TEST
READ
WRITE
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
TEST
READ
WRITE
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
TEST
READ
WRITE
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
TEST
READ
WRITE
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
TEST
READ
WRITE
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.