Masking the Problem
From my past posts, you may have guessed that I'm in the middle of optimizing a web application that accesses a database. Our studies have shown that a combination of missing indexes, unnormalized data, and inefficient queries are the root cause for this application's poor performance. The optimal solution involves reorganizing the database schema and rewriting our database access layer.
During a meeting to discuss these changes, another suggestion was made to help performance. There are certain instances where we could save few trips to the database (per request) by reusing session information that is unlikely to change (whether this data should actually be in the session or not is a subject for another post). This enhancement requires that we check the database for updates (using a new query) , and reuse the session information if the database has not changed since the previous request.
On the surface this looks like a reasonable approach, but I don't like making these types of changes as a first step to improve performance. First of all, it violates the 80/20 rule (or 90/10 or whatever) because the time saved by this enhancement is small in relation to all the processing we're doing per request. Secondly, enhancements like these mask the real problem - that we have a bad database design and we a doing a poor job accessing it. Finally, I'm a big believer in the KISS principle and when something goes wrong with application caching, my experience has been that this added complexity is difficult to debug.
Don't get me wrong, I feel that optimizations like caching are necessary in web applications, I just feel they shouldn't be explored until other, more obvious, issues have been addressed.
Side Note: The books SQL Tuning by Dan Tow, Pro MySQL by Michael Kruckenberg and Jay Pipes, and Hibernate in Action by Christian Bauer and Gavin King have been instrumental in helping to identify solutions to these problems.
During a meeting to discuss these changes, another suggestion was made to help performance. There are certain instances where we could save few trips to the database (per request) by reusing session information that is unlikely to change (whether this data should actually be in the session or not is a subject for another post). This enhancement requires that we check the database for updates (using a new query) , and reuse the session information if the database has not changed since the previous request.
On the surface this looks like a reasonable approach, but I don't like making these types of changes as a first step to improve performance. First of all, it violates the 80/20 rule (or 90/10 or whatever) because the time saved by this enhancement is small in relation to all the processing we're doing per request. Secondly, enhancements like these mask the real problem - that we have a bad database design and we a doing a poor job accessing it. Finally, I'm a big believer in the KISS principle and when something goes wrong with application caching, my experience has been that this added complexity is difficult to debug.
Don't get me wrong, I feel that optimizations like caching are necessary in web applications, I just feel they shouldn't be explored until other, more obvious, issues have been addressed.
Comments