Tuning CF 8.0.1 64 bit

Recently we worked on an application for a large association in DC that generates about 60% of the association's revenue. The application had grown in features and users over several years and the code was in need of tuning, with slow performance and frequent server crashes. It was running on CF 7 on Linux.

Improvements

We recently helped setup the development server with a 64-bit operating system, and the 64-bit version of ColdFusion 8.0.1. Additionally, we also did performance and memory tuning.

CF8 itself has been shown to have better object creation performance as well as general speed improvements across the board (see Adobe’s performance brief www.adobe.com/products/coldfusion/pdfs/cf8_performancebrief.pdf). We tuned JVM configuration parameters (memory and garbage collection), recommended and helped setup the updated Java runtime 1.6 updater 12, which fixes a major performance bug and allowed us to take full advantage of CF 8’s and Java 1.6’s performance and memory improvements. We even discovered CPU and memory issues that were fixed by applying a cumulative hotfix for ColdFusion.

The result of all this is much more manageable CPU and memory usage, as well as better initialization and search performance. Furthermore, many cases of CFC methods that were missing var scoping on local variables were fixed; this affecting stability and performance.

Maintainability

Here we added Application-level service objects to Coldspring, to make the code more maintainable. We also had Coldspring create more of the sub-objects, to make the object hierarchy more visible.

Generally, where these service objects called global objects directly (configuration or other service objects), changed to pass those in via the Coldspring configuration. Many places were able to reduce to passing in specific configuration properties (like a DSN), rather than passing in the whole object. This goes a long way towards reducing interdependency, which makes them better able to test.

We removed some reserved words in method names, so we could use automatic CFC documentation tools. We also had consistent use of init() methods; adding to objects that didn’t have them, and then using consistently when creating. This better enables use of Coldspring, and makes usage overall more readable.

We then made a switch to Fusebox 5.5, which allowed us to move customized code out of the core files, and into the index.cfm, which calls it; this included application-specific parameters retrieved from configuration or CGI variables. This will make it much simpler to swap out the framework for later versions.

Scalability

Finally, we developed and ran a profiling tool, which temporarily modified all of the components to save logging information on when objects are created and methods are called. We ran on some sample searches, logged the number of times objects are created and methods are called. We were then able to reduce use of some classes used in application.

There was one class that was created 160 times for each search result page that we were able to convert to a structure generated by a service object; this service object only needs to be created once per session, saving a whole lot of object creation.