Web Application Performance Design Inspection Questions - Caching

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Srinath Vasireddy, Ashish Babbar, Rico Mariani, and Alex Mackman


Caching Issues



Not using caching when you can

Round trips to data store for every single user request, increased load on the data store.

Updating your cache more frequently than you need to

Increased client response time, reduced throughput, and increased server resource utilization.

Caching the inappropriate form of data

Increased memory consumption, resulting in reduced performance, cache misses, and increased data store access.

Caching volatile or user - specific data

Frequently changing data requires frequent expiration of cache, resulting in excess usage of CPU, memory, and network resources.

Holding cache data for prolonged periods

With inappropriate expiration policies or scavenging mechanisms, your application serves stale data.

Not having a cache synchronization mechanism in Web farm

This means that the cache in the servers in the farm is not the same and can lead to improper functional behavior of the application.

To assess how effectively your application uses caching, review the following questions:

  • Do you cache data?
  • Do you know which data to cache?
  • Do you cache volatile data?
  • Have you chosen the right cache location?
  • What is your expiration policy?

Do You Cache Data?

Do you make expensive lookups on a per-request basis? If you operate on data that is expensive to retrieve, compute, or render, it is probably a good candidate for caching. Identify areas in your application that might benefit from caching.

Do You Know Which Data to Cache?

Identify opportunities for caching early during your application's design. Avoid considering caching only in the later stages of the development cycle as an emergency measure to increase performance.

Prepare a list of data suitable for caching throughout the various layers of your application. If you do not identify candidate data for caching up front, you can easily generate excessive redundant traffic and perform more work than is necessary.

Potential candidates for caching include the following:

  • Relatively static Web pages. You can cache pages that do not change frequently by using the output cache feature of ASP.NET. Consider using user controls to contain the static portions of a page. This enables you to benefit from ASP.NET fragment caching.
  • Specific items of output data. You can cache data that needs to be displayed to users in the ASP.NET Cache class.
  • Stored procedure parameters and query results. You can cache frequently used query parameters and query results. This is usually done in the data access layer to reduce the number of round trips to the database. Caching partial results helps dynamic pages generate a wide set of output (such as menus and controls) from a small set of cached results.

Do You Cache Volatile Data?

Do you know the frequency at which data is modified? Use this information to decide whether to cache the data. You should also be aware of how out-of-date the data you display can be, with respect to the source data. You should be aware of the permissible time limit for which the stale data can be displayed, even when the data has been updated in its source location.

Ideally, you should cache data that is relatively static over a period of time, and data that does not need to change for each user. However, even if your data is quite volatile and changes, for example, every two minutes, you can still benefit from caching. For example, if you usually expect to receive requests from 20 clients in a 2-minute interval, you can save 20 round trips to the server by caching the data.

To determine whether caching particular sets of data is beneficial, you should measure performance both with and without caching.

Have You Chosen the Right Cache Location?

Make sure you cache data at a location where it saves the most processing and round trips. It also needs to be a location that supports the lifetime you require for the cached items. You can cache data at various layers in your application. Review the following layer-by-layer considerations:

Do you cache data in your presentation layer?

You should cache data in the presentation layer that needs to be displayed to the user. For example, you can cache the information that is displayed in a stock ticker. You should generally avoid caching per-user data, unless the user base is very small and the total size of the data cache does not require too much memory. However, if users tend to be active for a while and then go away again, caching per-user data for short time periods may be the appropriate approach. This depends on your caching policy.

Do you cache data in your business layer?

Cache data in the business layer if you need it to process requests from the presentation layer. For example, you can cache the input parameters to a stored procedure in a collection.

Do you cache data in your database?

You can consider caching data in temporary tables in a database if you need it for lengthy periods. It is useful to cache data in a database when it takes a long time to process the queries to get a result set. The result set may be very large in size, so it would be prohibitive to send the data over the wire to be stored in other layers. For a large amount of data, implement a paging mechanism that enables the user to retrieve the cached data a chunk at a time. You also need to consider the expiration policy for data when the source data is updated.

Do you know the format in which the cached data will be used?

Prefer caching data in its most ready state so that it does not need any additional processing or transformations. For example, you can cache a whole Web page by using output caching. This significantly reduces the ASP.NET processing overhead on your Web server.

Do you write to the cache?

If you write user updates to a cache before updating them in a persistent database, this creates server affinity. This is problematic if your application is deployed in a Web farm, because the request from a particular client is tied to a particular server, due to localized cache updates.

To avoid this situation, you should update cached data only to further improve performance and not if it is required for successful request processing. In this way, requests can still be successfully served by other servers in the same cluster in a Web farm.

Consider using a session state store for user-specific data updates.

What Is Your Expiration Policy?

An inappropriate expiration policy may result in frequent invalidation of the cached data, which negates the benefits of caching. Consider the following while choosing an expiration mechanism:

How often is the cached information allowed to be wrong?

Keep in mind that every piece of cached data is already potentially stale. Knowing the answer to this question helps you evaluate the most appropriate absolute or sliding expiration algorithms.

Is there any dependency whose change invalidates the cached data?

You need to evaluate dependency-based algorithms. For example, the ASP.NET Cache class allows data expiration if changes are made to a particular file. Note that, in some scenarios, it might be acceptable to display data that is a little old.

Is the lifetime dependent upon how frequently the data is used?

If the answer is yes, you need to evaluate the least recently used or least frequently used algorithms.

Do you repopulate caches for frequently changing data?

If your data changes frequently, it may or may not be a good candidate for caching. Evaluate the performance benefits of caching against the cost of building the cache. Caching frequently changing data can be an excellent idea if slightly stale data is good enough.

Have you implemented a caching solution that takes time to load?

If you need to maintain a large cache and the cache takes a long time to build, consider using a background thread to build the cache or build up the cache incrementally over time. When the current cache expires, you can then swap out the current cache with the updated cache you built in the background. Otherwise, you may block client requests while they wait for the cache to update.

More Information

For more information, see the following resources:

Personal tools