Caching
This chapter checks HopPress against its performance and scalability requirements. The check fails, so the chapter introduces caching as the way to meet them. It starts by defining performance and scalability and how they are measured. Then it runs a load test, tries the cheap fixes first, and profiles a request to find which step takes the most time. After that it covers what a cache is, where it can live, how the application writes to it, and how the cached copy is kept fresh.
After reading this chapter, you should be able to:
- Define response time, latency, service time, throughput, load, and scalability, and name the kinds of growth a system can face
- Explain what a load test measures, why an average response time hides slow requests, and how to read a result at a percentile
- Clarify a response-time requirement by choosing the percentile it is read at
- Explain what a connection pool does, why its size is a limit, and what vertical scaling gains and where its limit is
- Distinguish a load test from profiling, and state the rule for performance work: find the bottleneck and fix that
- Define a cache as an architectural role, define hit, miss, and hit ratio, and use the hit ratio to judge whether a cache is worth having
- Distinguish an in-process cache, a separate cache server, a database used as a cache, and the database’s own buffer pool, and state what each saves
- Describe the cache-aside pattern and the common eviction policies
- Describe invalidation and expiry, and choose a time to live from the requirements of the system and how users use it