When things work great in testing it doesn’t necessarily mean that everything works great in production. There are many things that might be different – such as: much higher load than tested, different hardware, external services that couldn’t be tested, “Real Users” that execute transactions that weren’t tested.
This blog marks the start of a series of blog posts covering the Top Performance Mistakes when moving from Test to Production. All examples are taken from real life applications we have been working with. I will start the series with one that many application owners may not think about: Excessive Logging.
Logging is important – but handle with care
We all know that logging is important as it provides valuable information when it comes to troubleshooting. Logging Frameworks make it easy to generate log entries and, with the help of tools, its becoming easier to consume and analyze log files when it is time to troubleshoot a problem. But what if there is too much log information that nobody looks at anyway, that just fills up your file system and – the worst thing – seriously impacts your application performance and with that introduces a new problem to you application? The following two examples are taken from an online web application running on Tomcat. We can easily see how the current logging settings can become a real problem once this application gets deployed in testing.
Example #1: Excessive use of Exception objects to log Stack Trace
In this example the Tomcat Connection Pool was used with the setting “logAbandoned=true”. In case the Connection Pool runs into a problem it starts logging a lot of information including full stack traces of where the application tried to get a connection from the pool. In case of this application a typical transaction executed several hundred database queries. Most queries were executed on separate connections which results in about as many getConnection calls as executedQuery calls