Performance Under the Covers in ColdFusion MX 6.1
Note: Macromedia ColdFusion MX 6.1 is now available for trial and purchase.
Find out more about Macromedia ColdFusion MX 6.1>One of the most exciting features of the ColdFusion MX 6.1 release is enhanced performance over previous releases of the product. These performance increases fall into various categories, from the response time for page requests to a server under load, to the response time for a single page request the first time it loads, to the number of email messages that the server can send in a time period.
We have enhanced performance in all of these areas with ColdFusion MX 6.1. ColdFusion MX introduced a brand new architecture based on the Java™ 2 Enterprise Edition (J2EE), leveraging the latest industry standards and infrastructure to deliver scalability, reliability, and the power of the Java platform without the complexity. This new architecture also provided very good performance characteristics, outperforming earlier releases, including ColdFusion 4.5, and ColdFusion 5. Read the ColdFusion MX Performance Brief for specific performance statistics for ColdFusion MX 6.1. For ColdFusion MX 6.1, Macromedia made a significant engineering effort to leverage this architecture further to create a faster product.
Compiler Performance
Compiling pages in ColdFusion MX. The new Java architecture introduced in ColdFusion MX means that the ColdFusion no longer interprets the CFML code at runtime (as it did in ColdFusion 5 and earlier editions); instead, it translates CFML to Java code, compiles it to Java bytecode (class file), and runs it inside the J2EE Application Server's Java Virtual Machine (JVM). This process happens the first time you request a CFML page (from now on, I'll use the term first-request response time to refer to this unit of measurement). Subsequent requests load the same class from the cache and do not require recompilation. In ColdFusion MX, this process was fairly expensive because the server called the Java compiler to convert the Java code to bytecode. The result is a fairly long first-request response time for CFML pages compared to normal runtime-response time. For example, in ColdFusion 5, a page that has a first-request response time of 10 milliseconds might have first-request response time of 1600 milliseconds in ColdFusion MX.
Comparing ColdFusion MX with ColdFusion 5 and earlier editions. ColdFusion 5 and earlier editions, with their older architecture based on a C++ codebase, worked differently. Internally, they compiled CFML to PCode the first time a page was requested and then interpreted each subsequent request. Although ColdFusion MX has faster runtime performance than ColdFusion 4.5 and ColdFusion 5, the first-request response time was slower. Developers traded the benefit of faster runtime performance with a slower first-request response time performance as simply a side effect of the new architecture—something that they endured to take advantage of all that J2EE had to offer.
Compiling pages in ColdFusion MX 6.1. Researching the development habits of CFML coders showed that the first-request response time performance was important to productivity due to the habitual way coders make changes to a CFML page, save the changes, and then load the page in the browser. They repeat this process as they work on an application. A developer might change and reload each page several times within a few minutes. This, in turn, forces as many recompilations and requires the developer to endure the long first-request response time.
We enhanced ColdFusion MX 6.1 dramatically in its first-request response time to provide greater productivity to developers. We accomplished this by making a very inventive change to the architecture that allowed us to eliminate the slow step of compiling the translated Java code to bytecode. In Java, file input and output (I/O) is very expensive, performance-wise (and elsewhere, too). We eliminated the I/O associated with the compilation allowing for the entire process to happen very quickly.
Rather than translating CFML to Java and then compiling the Java to bytecode, ColdFusion MX 6.1 translates the CFML directly to bytecode. To do this, we introduced special Java bytecode generation and manipulation logic along with the CFML compiler package of the ColdFusion runtime. Thus, a page that may have had a 1600 ms first-request response time in ColdFusion MX may now return a response in under 100 ms on that first request.
Runtime Performance
We tuned the runtime engine and analyzed third party components in ColdFusion MX to improve runtime performance.
Fine Tuning the Runtime Engine. Enhancements in runtime performance are perhaps the most compelling of all the improvements made to ColdFusion with the 6.1 release. The end result is improved user experience and higher return on investment (ROI) on ColdFusion MX 6.1 websites due to decreased response time and more load-bearing capacity per server. This increased capacity per server machine brings cost savings for customers using earlier versions of ColdFusion.
To improve runtime engine performance, we searched the entire ColdFusion MX codebase for bottlenecks and then tuned the server runtime code to eliminate them wherever possible. We achieved this by running real-world applications on special ColdFusion MX 6.1 installs built with instrumentation. Under load, we looked at the inner workings of the engine under a microscope. As we uncovered and removed each bottleneck, we measured each change individually to see how it impacted the overall performance of the server. Most of the changes were small, resulting in incremental improvements, sometimes as small as 1-2%, but their cumulative effect was dramatic.
The engineering team leveraged the vast CFML customer application repository maintained by the ColdFusion quality assurance team. Consisting of nearly one hundred customer applications and approximately 2.4 million lines of CFML code, there was an abundance of applications to use for analyzing CFML usage patterns and to look for bottlenecks in real-world customer settings.
Analyzing these 2.4 million lines of CFML code yielded the top twenty tags and functions that customers use in their applications. This valuable piece of information allowed us to focus our tuning efforts to the parts of the runtime engine that get the most exposure. This effectively makes the average ColdFusion application much faster.
Beta customers were also extremely valuable in helping us tune the runtime engine. FuseTalk Inc. partnered with us during the beta cycle to help us tune the runtime engine with their products, including Fusetalk Professional, the world's most popular premium web discussion forum. Jason Clark, Fusetalk CTO, and Dominic Plouffe, Fusetalk VP of Research and Development, traveled to our Newton, Massachusetts performance lab to help us find bottlenecks in the runtime engine while Fusetalk Professional ran under load. This work was highly successful and revealing, yielding a nearly 40% performance improvement with FuseTalk running on ColdFusion MX 6.1 instead of ColdFusion MX.
In the relentless search for more bottlenecks to conquer, our engineering team scoured the web for more CFML code to enhance to make applications run faster on ColdFusion MX 6.1. Frameworks were an attractive option to look at because many applications reuse the same base framework code. If we could remove bottlenecks that are encountered in low-level Fusebox application code, for instance, we could help virtually all Fusebox applications run faster. We analyzed Fusebox 3, Fusebox 4, and Fusebox MX applications and made incremental performance gains as a result.
In addition to tuning the ColdFusion runtime engine, we also updated and optimized the JRun Application Server and JRun Web Connectors. As the integrated J2EE Application Server in ColdFusion, this work was important because JRun serves as the foundation for ColdFusion.
Third Party. ColdFusion MX 6.1 updates the latest driver suite to DataDirect Connect for JDBC 3.2. We worked closely with DataDirect to maximize the performance of these drivers for ColdFusion MX 6.1 Enterprise customers. The result is a significant increase in performance and scalability with ColdFusion MX 6.1 compared to ColdFusion MX.
ColdFusion MX 6.1 provides an important update to the Java Virtual Machine (JVM). The JVM is important because it is the only piece of software that runs Java code on a computer, compiling Java bytecode to machine instructions. It's the core of any Java implementation. ColdFusion MX 6.1 was optimized for and ships with the new Sun 1.4.2 JVM (also known as the Java 2 Platform, Standard Edition version 1.4.2). With the 1.4.2 release of the Sun JVM, many performance and stability enhancements from Sun are now available to ColdFusion customers. Performance was a major goal for Sun Microsystems with the release of 1.4.2 (just as it was a major goal for Macromedia with ColdFusion MX 6.1), and by working with Sun and the 1.4.2 JVM early in its release cycle, we were able to ensure the optimal integration of ColdFusion MX 6.1 and the 1.4.2 JVM. Read more about the most recent JVM in the Sun J2SDK 1.4.2 Performance Whitepaper.
ColdFusion MX 6.1 provides support for the latest versions of several vendor operating systems, including Microsoft Windows Server 2003, SuSe Enterprise Server 8.2, Red Hat Enterprise Server AS 2.1, Sun Solaris 9, IBM AIX 5L for Power v 5.2, and HP-UX 11i. This allows ColdFusion customers to take advantage of performance improvements in the latest operating system versions. For example, Windows Server 2003, which ColdFusion MX 6.1 supports, was measured as three times faster than Windows NT 4 on the same hardware for serving dynamic web content. Read more about this in the Microsoft Lab Report: Windows Server 2003 Outperforms Predecessors.
E-Mail Handling Performance
Another important area of enhanced performance in ColdFusion MX 6.1 is in handling and delivering e-mail. Customers have long requested a more robust mail handling subsystem, capable of sending very high volumes of mail quickly, and ColdFusion MX 6.1 delivers. Macromedia lab tests clocked ColdFusion MX 6.1 sending well over one million e-mail messages per hour. This new found e-mail handling capability, when coupled with the extensive e-mail handling enhancements, allows for truly industrial strength e-mail applications. Whether for use with high volume lists or just rock solid stability for any application that needs to send e-mail reliably, ColdFusion MX 6.1 delivers.
ColdFusion MX and earlier versions had a single thread for delivering mail to the mail queue and a single thread for delivering mail from the queue to the SMTP server. ColdFusion MX 6.1 provides multi-threaded transport to the queue, and multi-threaded delivery from the queue to the SMTP server. You can now configure the number of threads used for each of these functions in the ColdFusion Administrator and ColdFusion server now pools the connections for reuse. Use caution, however, because, in many cases, adjusting these thread-level settings high enough can result in sending mail faster than your mail server can process it!
Read John Cummings' article, Making
the Most of E-Mail with the cfmail Tag Enhancements in
ColdFusion MX 6.1, for more details.
On their own, all of these performance improvements add up to a very exciting release of ColdFusion MX 6.1, and I haven't even detailed all of the other great enhancements and fixes. The product just feels faster than earlier editions when you use it, but measuring the changes reveals that it is objectively faster than previous editions. A faster ColdFusion MX equals cost savings and increased return on investment. So what are you waiting for? Give your customers the experience of faster performance in your applications—update to ColdFusion MX 6.1!
About the author
Jim has seven years experience building web applications and has been programming with ColdFusion since the release of version 2.0. He has built e-commerce sites and enterprise web applications for such customers as the U.S. Mint, the FAA, Pfizer, Pharmacia, The BOC Group, and Schering-Plough. Jim is an alumnus of the Johns Hopkins University where he graduated with a Bachelor's degree in Earth and Planetary Science. Jim is also a Microsoft Certified Database Administrator and a Macromedia Certified Advanced ColdFusion Developer.
Jim has worked as a technical editor and consultant on several popular ColdFusion books. For Macromedia, he works as Principal QA Engineer for ColdFusion concentrating most of his efforts on the performance of the product.
Submit feedback on our tutorials, articles, and sample applications.
