Home
10.2.3 Cache invalidations causing severe performance impacts
Cache invalidation was not carefully considered before the shop was opened to the public. Initially the online shop cache pages were set to never expire. This had great performance, but content updates became a problem. We found there was no way to identify the cache pages invalidated by database updates. Consequently, a method was developed to invalidate the entire cache when data propagation from the staging instance to the production database was completed.
Emptying the cache caused an immediate and catastrophic performance impact. As mentioned before, the online shop was open to the public when this was found.
Because there was no identifiable correlation between cache pages and database updates, and we could not invalidate the entire cache in one operation, the only remaining solution was to invalidate pages after an elapsed time period.
The cache invalidation policy was changed to invalidate pages 8 hours after page generation. This was a less than ideal policy, but it was the best compromise available at the time. The business unit responsible for owning and running the online shop was made aware that it could be as much as 8 hours from product update to cached page update. This meant old data could still be on display to real customers.
A proposal to build an application to warm up the cache was rejected for three reasons:
1. No accurate traffic pattern had emerged to show the pages to pre-warm the cache with.
2. The inefficiency of the WebSphere Commerce application code ensured a warm-up operation would cause an operational outage to the online shop.
3. During a programmatic warm-up, the online shop would perform so poorly it appeared to users to be unavailable.