Designing Steps for Caching
Designing Steps for Caching
1. What to cache?
- Create a list of the data to cache in each layer of your application.
- Consider caching the following types of data:
- Application-wide or relatively static data.
Consider caching relatively or fully static data that applies to all users of the application. For examples, product categories, product list and product catalog.
- Relatively static Web pages.
Consider caching the output of Web pages or sections of Web pages that do not change frequently.
- Stored procedure parameters and query results.
Consider caching frequently used query parameters and query results.
- Application-wide or relatively static data.
2. Where to cache?
- In-process cache or Out-process cache?
- In case of out process cache, choose any of the below:
- Centralized cache
- Distributed cache
- Or Replicated cache
- Also, consider state management of your application.
3. In Which format to cache data?
- Choose XML serializer or a binary serializer.
- Encryption is required or not.
4. When to remove cached data?
Identify a suitable cache management strategy:-- Time-based expiration:
The cached data is expired or invalidated based on relative or absolute time intervals.
- When to choose:
- The cache data is volatile.
- The cached data is regularly updated.
- or the cached data is valid for only a specific time or interval.
- When to choose:
- Notification-based expiration:
The cached data is expired or invalidated based on notifications from internal or external sources.
- When to choose:
- You are working with non-volatile cache data.
- The cached data is updated at irregular intervals.
- or the data is valid unless changed by external or internal systems.
5. When to load into cache?
- Proactive loading:Choose this to retrieve all of the data for the application when it starts and then cache it for the lifetime of the application.
- Proactive loading is a good choice if your cached data is relatively static or has a known update frequency, a known lifetime, and a known size.
- It is also a good choice if the source for your cached data is a slow database; or data is retrieved across a slow network or from an unreliable Web service.
- Reactive loading: Choose this to retrieve data as it is requested by the application and then cache it for future requests.
- Reactive loading is a good choice if your cached data is relatively volatile, you are not sure of your cache data lifetime, your cached data volume is large, and your cache data source is reliable and responsive.
Choose this to retrieve all of the data for the application when it starts and then cache it for the lifetime of the application.
- Proactive loading is a good choice if your cached data is relatively static or has a known update frequency, a known lifetime, and a known size.
- It is also a good choice if the source for your cached data is a slow database; or data is retrieved across a slow network or from an unreliable Web service.
Choose this to retrieve data as it is requested by the application and then cache it for future requests.
- Reactive loading is a good choice if your cached data is relatively volatile, you are not sure of your cache data lifetime, your cached data volume is large, and your cache data source is reliable and responsive.