From e161b29eb1c61878ea17f1e1cb034610104ac0e4 Mon Sep 17 00:00:00 2001 From: Donne Martin Date: Wed, 1 Mar 2017 20:36:47 -0800 Subject: [PATCH] Add Application caching section --- README.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/README.md b/README.md index fe63f61..b406528 100644 --- a/README.md +++ b/README.md @@ -1234,3 +1234,21 @@ Caches can be located on the client side (OS or browser), [server side](#reverse ### Database caching Your database usually includes some level of caching in a default configuration, optimized for a generic use case. Tweaking these settings for specific usage patterns can further boost performance. + +### Application caching + +In-memory caches such as Memcached and Redis are key-value stores between your application and your data storage. Since the data is held in RAM, it is much faster than typical databases where data is stored on disk. RAM is more limited than disk, so [cache invalidation](https://en.wikipedia.org/wiki/Cache_algorithms) algorithms such as [least recently used (LRU)](https://en.wikipedia.org/wiki/Cache_algorithms#Least_Recently_Used) can help invalidate 'cold' entries and keep 'hot' data in RAM. + +Redis has the following additional features: + +* Persistence option +* Built-in data structures such as sorted sets and lists + +There are multiple levels you can cache that fall into two general categories: **database queries** and **objects**: + +* Row level +* Query-level +* Fully-formed serializable objects +* Fully-rendered HTML + +Generaly, you should try to avoid file-based caching, as it makes cloning and auto-scaling more difficult.