Don’t cache something if it takes longer to retrieve it from the cache than it takes to generate it in the first place.
Corollary: Improving performance on the cache mechanism allows more stuff to be cached effectively.
This was discovered while attempting to speed up the work list and order detail pages. Fortunately, adding an index in a particular place in the database was enough to get the cache retrieval and validation to be well under a millisecond.
That, combined with roughly eight hours of tweaking code and database calls, means that an average order detail page request now only requires 182 database calls, down from 689 (74% reduction), and is generated (in most cases) in well under a second, even without touching the cache.
With the cache, it’s generated in roughly a tenth of a second (with about ten database calls for the entire request), though I still have some work to do, since it’s taking the browser between a quarter and half a second to render.
The work list load time is just under a second now, with some selective caching, down from about 2-3 seconds, using a test set of 40 active mailings. That’s fast enough for now. Database calls also dropped from 789 to 402, which is a nice bonus. At 100 active mailings, it slows down to about 1.5 seconds with the selective caching (down from about 10 beforehand), so I’ll probably need to do some more performance work once we start seeing that on a regular basis.
