Improving ColdFusion Application Performance

The purpose of this article is to demonstrate how to both improve existing ColdFusion applications and even better, how to architect and build them so they will scale flawlessly, from day one.  Everything in this article is drawn from 14 years of 3D ColdFusion application work. 3D; designing, developing and deploying applications.

In 1996, I took up ColdFusion, as a business manager in need of a solution. This speaks to the main strength that propelled ColdFusion to become a major web language; its rapid application development capabilities, (RAD);  largely enabled by its ease of use.  I was not a developer and even so, ColdFusion enabled me to build what became the largest web based portal for diesel engine and generator parts, Power Bank International.  

We were getting 10,000 hits a day at one point, which back in 1997 was a lot, for a niche market site and that brings me to one of the main points of this article.  Now, 14 years later, I spend most of my time helping many clients to troubleshoot existing applications and improve performance.  Sometimes, I get the chance to help clients to get this right from the outset; this latter work is the best of all worlds.

The ColdFusion Myth

There is a point of view which says ColdFusion does not perform optimally and will not scale well.  As I mention in the Introduction above, I have been using ColdFusion since version 1.54 in 1996.  In addition, I have spent the last 11 years helping clients to improve performance and to create ColdFusion applications from the ground up.  During that time I have worked with every version of ColdFusion, some were not good; 4 and 6 in particular, but most were filled with new amazing development paradigms, Custom Tags, UDF’s, CFC’s etc.  In this long period of working with ColdFusion, it was rarely ColdFusion itself that caused any great issues, in fact most of the time the problems were caused by the data-tier and the interaction of ColdFusion with the data-tier.

How/where does ColdFusion Run?

Since version MX 6-6.1 ColdFusion has been a Java J2EE-JavaEE application server.  J2EE-JavaEE are recognized standards across different products; Resin, TomCat, WebSphere, WebLogic etc. All these need a Java Virtual Machine or JVM and a Servlet Container as core components.  In the case of ColdFusion, JRun is the default Servlet Container with the Sun JVM.  However, one of the strengths of ColdFusion is that it can run on any JVM in any Servlet Container and across all well know operating systems.  To get an idea of ColdFusion and it’s place in the overall infrastructure, here is a diagram showing where ColdFusion sits:

If this were a multiple instance install, there would be multiple “Java Application Server <COLDFUSION>”.  This is an important detail to know about because one of the debilitating issues for Java applications, such as ColdFusion, is “out of memory” issues. The JVM has a memory “heap” which in turn comes from the overall RAM of the operating system sometimes in the “exchange” of allocation and usage between the JVM heap and the system RAM, there are problems.  The best advice I have is wherever possible use 64-bit systems and if you have 32-bit have at least 4GB of total RAM.  Once again, this behavior, which will manifest itself as apparent ColdFusion problems; is not.

Existing Problems - The Best Approach

As with any computer based paradigm, ColdFusion handles and manipulates data, sometimes creating data in that process.  That data has to get from the web browser or other point of emanation to the web-application server, often interacting with back-end systems; mostly databases and then back to the web browser or other point of emanation.  This is known as the request/response cycle.  If we have a slow/unresponsive application to troubleshoot, knowing where the slow-down is, is always critical.  Most times, ColdFusion gets the blame and as already stated, in most cases, it is not the actual cause of the problem.  We need to look at every piece of infrastructure in order to pinpoint the actual problem.  One more important point, ColdFusion does an incredible job in logging items.  In particular, the *{instance}-out.log which is located in one of two places:

Standard non multiple instance install
{drive}\{coldfusion root}\runtime\logs

Multiple instance install
{drive}\JRun4\logs

 
This log where *{instance} is the actual name of the ColdFusion server/instance, is a wealth of information about what is going on inside ColdFusion and also the main dependency points. Always check this log regularly.

Another really good tip for troubleshooting existing problems is to enable “enhanced/metrics logging”.  I always recommend enabling this and leaving it running, the overhead is negligible and the payback in vital information is immense.  This will show the state of threads and memory in whatever time-slice you set.  Here is how, locate the jrun.xml file in one of these two places…

Standard non multiple instance install
{drive}\{coldfusion root}\runtime\servers\SERVER-INF

Multiple instance install
{drive}\JRun4\servers\SERVER-INF

In the jrun.xml file search for the word “metrics”. The first occurrence will be in this section around 1/3rd of the way through the file.

<!-- This Service provides metrics information -->                      
<!-- ================================================================== -->
<service class="coldfusion.server.jrun4.metrics.MetricsServiceAdapter" name="MetricsService">
    <attribute name="bindToJNDI">true</attribute>
</service>

Make sure that this section is uncommented. 

The next section needing a change is a little further down the file and here we change a “false” value to “true”…

<service class="jrunx.metrics.MetricsService" name="MetricsService">
    <attribute name="bindToJNDI">true</attribute>
  </service>

Lastly, we will add enhanced logging to break out a separate log for the metrics themselves, we add the value “–{log.level}”…

<service class="jrunx.logger.FileLogEventHandler" name="FileLogEventHandler">
        <attribute name="filename">{jrun.rootdir}/logs/{jrun.server.name}-{log.level}.log</attribute>

Metrics logging is very powerful enabling us to view both thread and memory behavior over a period of time both in a dedicated log and also in the {instance}-out.log which is critical information if trouble hits, helping pinpoint trends such as memory leaks.  Use of a server monitor is also useful, I prefer one of two third party products,  FusionReactor or SeeFusion, ColdFusion also has one but it can certainly cause issues if used incorrectly.

As a final note on dealing with existing problems it is important to consider load-testing in a test environment to reproduce production problems.  We will go into this in greater detail in the next section.

Getting It Right From Day One

There is a foolproof way to build ColdFusion Applications, if the following steps are followed.  We call this “The Application Lifecycle” and here are the details…

Step 1: User needs - Wireframe/Prototype

Capture all user needs before starting to code and get them to sign off on the fact that you have captured what they need.  Also and ideally, give them an adequate feedback mechanism which is dynamic. As I mentioned above, Hal Helms created a construct in ColdFusion called "DevNotes" which when combined with a WireFrame presented a very potent way to glean feedback from the users before coding starts.

During this main functionality gathering phase we use two major "sub phases".  The first is to create a click able "wireframe" with no graphics, I stress this because some firms call the look and feel phase (prototype) the "wireframe" phase, in our opinion, a wireframe should have no graphics, but should be realistic model with click-throughs.  Once the client has approved the click able model we can then add graphics to create a prototype.  

Once the client has approved the prototype we then move to the development phase.  

Step 2: Development/Unit Testing

In our shop we develop locally and each developer has a developer edition of ColdFusion and any other copies of things they may need, a database for instance. The main point is that every developer is independent and can function from wherever they may be; we are fanatical about telecommuting for both developer life-style and ecological reasons.  No code can be marked to go to Integration Testing until all unit tests complete successfully and we are not just talking about unit tests as in OO-CFC constructs, we mean all code functions without breaking on the developers local system.

Step 3: Development/Integration Testing

Here we take the code from all developers and move it to a central development server and test the whole application to make sure that code from one developer does not break code from another.  If any code does break it is sent back to the original developer to be fixed and this iteration continues until all code in the Integration Testing environment functions without fault, at which point it is moved to QA-Load Testing.

Step 4: QA-Load Testing

This is the most often missed phase in application development and it is a critical one that should never be missed; in fact almost all clients we have helped in our troubleshooting practice have problems because they did not load-test the application.  We advise and practice load testing to at least 150% of the expected load and we also get the client to state what the minimum acceptable page response time is.  The application should not be moved to production until it has passed all load testing which means it is responding to the required client page response time at 150% of expected maximum load.  Once again code is iterated back to developers and back through Unit Testing, Integration Testing and Load Testing.

Step 5: Production

After following the first 4 steps of the application lifecycle and only after these have been passed, we are now ready to deploy the application to Production.  There is sometimes a separation between Load Testing and QA where the QA environment is a direct copy of actual Production, this is an additional step which is not necessary but nice to have.  

ColdFusion Code Performance Tips

If all points in the previous section are followed, any code related ColdFusion issues will be discovered before getting to production.  There are two other pointers I can give to aid in basic ColdFusion performance.

1. Upgrade to ColdFusion 9 (there are very significant performance gains.
2. Refer to this article, from Adobe, on optimal coding for performance in ColdFusion.

Conclusion

ColdFusion is a highly scalable well performing language.  From the developer perspective ColdFusion Markup Language (cfml) is a very enjoyable language to work in, with all sorts of extensibility.  From a management perspective, the extensibility of ColdFusion makes it a very cost-effective option and its ability to run on Unix, Windows and Osx brings unbridled flexibility. 

Key Points to Remember

• Establish enhanced/metrics logging and monitor the resulting logs, regularly.
• By following The Application Lifecycle no code will reach production which could cause issues. 
• Sizing the resources actually needed to support your application, through iterative load-testing, will also ensure scalability with performance.
• The optimal environment for ColdFusion applications is ColdFusion 9 on 64-bit systems.