Are you still using the stock CF JVM? Stop today!

Posted by [Justice] in Coldfusion on December 12, 2008

Last week I rebuilt my work workstation (an old server actually, running 2003 Std server, dual 3.06 Xeon's, 4 gigs of ram, I love it).  Of course, that meant that Coldfusion gets re-installed.  One of the apps I am developing is a very large Model-Glue / Coldspring / Transfer ORM application that makes heavy use of objects.  There is a little script in the onAppStart method that times how long it takes for the application to fire up, and writes a log entry with that data. The first time I fired up the application after installing CF, it *really* felt like it was taking a long time, so I went to check out the log.

Application reloaded in 165.563 seconds from 127.0.0.1.

OK, yea, that took a long time.  Then I realize I hadnt updated the coldfusion JVM yet.  So I went out and grabbed the latest JDK (note, you need the JDK, not the JVM only), and installed it to the default windows location.  Since I have Coldfusion developer installed in multiserver mode, I went to e:\JRun4\bin\jvm.config, and I changed the java.home line near the top to point to my newly installed JDK location, like so:

java.home=C:/Program Files/Java/jdk1.6.0_11

Then I stopped and re-started the coldfusion services, and fired up my application again...

Application reloaded in 14.453 seconds from 127.0.0.1.

Holy smokes! What a huge difference, 151 seconds faster!  So, lets say you are reloading your application maybe 4 times an hour throughout the day to test changes. 8 hours a day (yea, right, dont I wish!), 40 hours a week, 52 weeks in a year....carry the 1.... wow, after a year of struggling along on the stock JDK with its classloader bug, you could waste 349 hours in a year JUST reloading this application.  I bet this is a worse case scenario of course, but this should illustrate why updating today is a good idea!

*edited*

Aaron Longnion has some questions regarding the status of the 'save class files' and 'trusted cache' options which may have effected this test, so I ran a more thorough test and noted times for each one. Upgrading to the latest JVM has not only been rock-solid for stability, but it has proven to be much faster for both my development and my production servers (in load testing, after tweaking garbage collection, my production cluster was able to handle a far greater traffic load with the updated JVM than without it)

Stock JVM, no cache or class file save First request to CF after restart 100.071
Stock JVM, no cache or class file save Reload app after initial request 13.767
Stock JVM, no cache or class file save Reload app 2nd time after restart 11.876
Stock JVM, primed trusted cache + save class files First request to CF after restart 82.706
Stock JVM, primed trusted cache + save class files Reload app after initial request 11.891
Stock JVM, primed trusted cache + save class files Reload app 2nd time after restart 10.297
1.6.0_11 JVM, no cache or class file save First request to CF after restart 54.230
1.6.0_11 JVM, no cache or class file save Reload app 2nd time after restart 13.734
1.6.0_11 JVM, no cache or class file save Reload app 2nd time after restart 12.297
1.6.0_11 JVM, primed trusted cache + save class files First request to CF after restart 38.453
1.6.0_11 JVM, primed trusted cache + save class files Reload app 2nd time after restart 11.031
1.6.0_11 JVM, primed trusted cache + save class files Reload app 2nd time after restart 9.844
Digg StumbleUpon Facebook Technorati Fav newsvine reddit FARK Google Bookmarks
  1. todd sharp

    #1 by todd sharp - December 12, 2008 at 8:53 AM

    Dumb question - why do you need the JDK and not just the JVM?

    Also - didn't know you needed to modify the jvm config file after upgrading. I'll have to remember that.

    PS holy crap your captcha is difficult.
  2. Justice

    #2 by Justice - December 12, 2008 at 9:01 AM

    JDK is required because ColdFusion needs a 'Hot-Spot JVM' which is not included in the JRE download.

    Yea, that captcha looks rough, lemme see what I can do to adjust that =)

    Chris
  3. Aaron Longnion

    #3 by Aaron Longnion - December 12, 2008 at 9:37 AM

    I have a hunch that it's because "Save class files" is turned on in your CF Admin (under Server Settings > Caching), and not the JVM version, that is causing the enormous performance difference. It's enabled by default. Per Adobe, "Select this option to save to disk the class files generated by the ColdFusion bytecode compiler."... so, probably the first time it compiled all the CF code into bytecode class files, and then after you changed JVM versions it reused those class files.

    Also, be careful that you're not using a JVM/JDK that Adobe doesn't support. I think they only support the version installed by default, and there could be potential bugs if you use an unsupported version. :(

    If that was turned on, can you do a new test to see the differences in load times? I'm interested to know. Thanks.
  4. todd sharp

    #4 by todd sharp - December 12, 2008 at 9:54 AM

    Aaron - there was a known bug in java < update 10 that caused this issue. It's well documented that update 10 fixed the class loading bug.
  5. Justice

    #5 by Justice - December 12, 2008 at 10:07 AM

    Aaron,

    I have updated this post with some additional details for you. I have been running 1.6.0_10 for more than a year on 3 production servers, as well as my local development system, and have been doing load testing, development, and 1 server in production now for approx a month on 1.6.0_11 with no issues.

    Chris Peterson
  6. cooljj

    #6 by cooljj - December 12, 2008 at 10:36 AM

    I've confirmed the same on a VERY large MachII application. I cleared the class cache before testing the startup time of my application after switching the JVM out. Can't remember the exact pre vs. post start up times but I remember the difference was huge.
  7. Jared Rypka-Hauer

    #7 by Jared Rypka-Hauer - December 12, 2008 at 12:25 PM

    It was a bug in one of the classloader classes that caused a huge delay in loading up dynamic classes. Since ColdFusion is heavily dependent on it, and CFCs in particular are dependent on it, loading up lots of classes takes a lot of time... and this had a particularly negative effect on frameworked apps that not only use CFCs themselves but run on frameworks that use CFCs as well.

    Fixing this bug was key for the CF community, and we've been telling pretty much anyone anywhere to update to the latest (currently Java 1.6_11) to get around this nasty bug.
  8. Ben

    #8 by Ben - December 12, 2008 at 12:37 PM

    Weren't we recommended not to use Java 6 because of a loader class bug that caused a massive slowdown? -- Especially those of us using frameworks? Was that issue resolved?
  9. todd sharp

    #9 by todd sharp - December 12, 2008 at 12:46 PM

  10. Aaron Longnion

    #10 by Aaron Longnion - December 13, 2008 at 5:47 AM

    Thanks for the update and new details. It's clear that upgrading to jdk1.6.0_11 is a good idea.

    Also, it's obvious to most of us, but wanted to mention that the upgrade is referring to CF 8, not previous versions of CF.

Comments are closed.