This is a brief overview of caching with emphasis on web software development.
What is caching?
Caching is the temporary storage of data in designed locations of a computing environment.
This is typically done to improve responsiveness and reduce roundabout requests to data stores.
It can also be used to reduce redundant computations, as might be the case with memoization, in which case the cached data might also be the results of computations that are stored for later retrieval.
The most common cache on the web is the HTTP cache, which represents data from responses that is stored in specific locations to be reused and managed according to HTTP cache specifications.
Where is the cache phisically stored?
Caches are physically stored in cache memory, which are typically chips (e.g. SRAM) that are integrated or interconnected with various processing units (e.g. CPU, GPU, etc.).
When is it appropriate to cache?
Expanding on what was said above, one use case is when the data is consistent during the session.
Another is in some situations when SQL queries are resource heavy.
It is worth mentioning that caching could be beneficial when the need to save costs is significant and a priority.
What are the most important attributes of HTTP caching?
Broadly speaking, there are two major attributes:
Freshness it's a property that sets an expiration frame for the cache and dictates whether or not the cached data is up to date and still relevant for use by the client.
Validation dictates the techniques for checking with the origin server the expired cached data in order to renew the expiration date or update the cache.
Are there any common practices regarding HTTP caching?
Be aware of heuristic caching, it basically involves always caching data on certain conditions unless otherwise specified. It is best to explicitly set some default cache settings based on your expectations.
For cache that needs to be updated more often than the expiration period suggests, it's good to consider cache busting, this means adding a unique symbol to its file name. That way, if a new update is available and ready, it can be downloaded by the browser because it is seen as a new resource, thus bypassing the original cache before the timeout expires.
Make it a habitt to check and enforce cache validation.
Usually don't cache resources that can't be cache busted. Do it unless you need more aggressive caching and have mechanisms in place that explicitly purge the cache when it's time for updates.
What are some common classifications of web caching?
Altough there are many carachteristics by which caches can be classified, here are two important ones:
Classification by accessibility:
- Private cache, here all cached data is available only to one client, the browser's cache system usually works as a private cache.
- Shared cache, here cached data is available and shared by multiple clients. This cache is usually based on a server somewhere on the network.
Classification by network location:
- On the browser, here the data is stored locally in the browser according to the set HTTP cache specifications.
- On a proxy server, either forward or reverse, here the data is stored on a proxy server inside the network according to the set HTTP cache specifications.
- On the origin server, here the data is stored on the server where the web application resides. The origin server cache might involve other caches aswell that differ from the HTTP cache (e.g. database cache and others).
How does caching looks like from the backend?
For origin server caching, depending on the technology, there could be different approaches to caching both in terms of API and implementation.
For example, from the perspective of an ASP.NET application, the following are the most common nuances used for caching:
- In-memory caching. The caching location for this is self-explanatory. It works best for affinity caching, when requests from a client are always routed to the same server.
- Distributed caching. It is best used in non-affinity cache. This works by distributing cached data between servers.
- Response caching. Its components, ResponseCacheAttribute and Reponse Caching Middleware, handle cache headers and stores data on the client/proxy server or origin server, according to the HTTP cache specification.
- Output caching. This expands on Response Caching Middleware and allows the origin server to store data according to its own specifications.
And that, folks, sums it up. If you find these articles valuable and you are interested in more technical discussions or business inquiries, feel free to subscribe or reach out to me!
Hopefully this has given you a better sense of understanding, or at least refreshed your knowledge of caching and its applications on the web. For further research on this topic, you can start with these:
- https://httpwg.org/specs/rfc9111.html
- https://www.rfc-editor.org/rfc/rfc9112.html
- https://www.rfc-editor.org/rfc/rfc9110.html
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
- https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
- https://www.mnot.net/cache_docs/#IMP-SERVER
- https://www.c-sharpcorner.com/UploadFile/225740/introduction-of-caching/
- https://learn.microsoft.com/en-us/aspnet/core/performance/caching/overview?view=aspnetcore-7.0
Top comments (0)