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)

#laravel #web development