2. Overview
• When to cache?
• What to cache?
• Page, Fragment and Data
• File system, Database and In-Memory
• Managing your TTL’s
• Clearing / Invalidation
3. When to cache?
• When you are accessing:
• Read only / mostly static data
• High latency external services
• Repeated page segments
9. File system
• PRO:
• Fast (depending on hardware)
• Persistent data
• Can operate on data via cron jobs
10. File system
• CON:
• Slow (depending on hardware)
• Open file limits of OS
• Max inode limits of OS/FS
• File lock issues on writes
• Does not scale well
11. Database
• PRO:
• Fast - Can rely on DB caching
• Flexable - Can scale
• Persistent data
• Can operate on data via cron jobs
12. Database
• CON:
• Relying on the DB being available
• Caching DB data back into the DB
• Flat file DB’s can have file lock issues
13. Database - Clarification
• When speaking of DB caching we are
talking about caching of content into a table
not the caching mechanisms of the DB
itself.
14. In-Memory
• PRO:
• Fast: Local memory access is cheap
• Distributed access is cheap (network)
• Flexible - can scale
15. In-Memory
• CON:
• Non-Persistent data (normally)
• No security built in
16. Managing your TTL’s
• Same content called from multiple API’s
• API 1 want’s data that is no older than 1
hour
• API 2 want’s data that is no older than 24
hours
17. Clearing your cache
• Data is no longer valid
• Clear to force a new call to the fresh data
18. Invalidating your cache
• What if you do not know all possible keys?
• Item ‘123456’
• ‘123456_methodname_param’
• You do not know all ‘methodnames’ or
‘params’
19. Invalidating your cache
• Create a “key” that you can invalidate
• Create a cache entry ‘ver_123456’ with
the value of the current unixtime
• ‘123456_unixtime_methodname_param’
• Now you can invalidate an item just by
changing the value of the ‘ver’ record, TTL
will take care old ver’s