Compound Theory

v2.0

Categories

  1. Transfer
  2. ColdFusion
  3. JRuby
  4. Java
  5. ColdSpring
  6. Squabble
  7. JavaLoader
  8. ColdDoc
  9. 2ddu
  10. AsyncHTTP
  11. OO Analysis and Design
  12. Flex
  13. Railo
  14. XML / XSL
  15. Hibernate
  16. ColdFusion Builder
  17. Fall
  18. Ubuntu
  19. XHTML / CSS
  20. Eclipse
  21. Git
  22. Oracle Database
  23. Usability / UI Design
  24. webDU
  25. cf.Objective()
  26. LWJGL
  27. cf.Objective(ANZ)
  28. Captcha
  29. MAX
  30. Melbourne CFUG
  31. Martial Arts
  32. Random Things
  33. Conduit

Recent Posts

  1. Multi-Monitor with One screen rotated with Nvidia Drivers - Ubuntu 12.10
  2. JRuby, LWJGL & OpenGL - Getting Started with Shaders
  3. JRuby, LWJGL & OpenGL - Drawing a Triangle
  4. Creating a window with LWJGL and JRuby
  5. Writing a Game: Feels like I'm Going Around in Circles...
  6. Procedural Land Creation with JRuby, Slick2D and Perlin Noise
  7. Simplify Threaded Processing with FutureThreadedWorker
  8. cf.Objective(ANZ) is only a Month Away!
  9. Git Workflow: The Case of the Lost Refactor
  10. ColdFusion 10 with Ubuntu Upstart

Projects

Recent Comments

  1. Thnx for publishing this information within your website....
  2. Yeah. I do think that this is a bug in Coldfusion 6. CF6 will not consider argument passing as assig...
  3. This is great! You can follow these instructions for distributing processes in ColdFusion. I tried t...
  4. Wonderful site you have here but I was curious about if you knew of any user discussion forums that...
  5. Refactoring mainly parts of other task is really an important process. According to me refactor shou...
  6. This article provides us the instructions for setting up ColdFusion 10 on an Ubuntu Server! The step...
  7. Totally cool. Saves writing a lot of boiler plate code. Your smart....
  8. Wish I could be there - those sound like great sessions! Hope the conference goes well!...
  9. Mark, is it possible to subsribe your blog? thank you...
  10. @Salvatore What I'm showing above is not functional programming. It's just using closures. Closure...
06 December 2007 04:14 PM

Huge Performance Gain in Moving ColdFusion 8 to Java 1.5

We have a reasonably large application that we have been building for the past 2 years or so, with MachII, ColdSpring and Transfer, and we moved over to ColdFusion 8, pretty much as soon as the Beta came out, and have been developing with it ever since.

To give you an idea of the size of the project, some metrics for you, we have 1064 CFCs, 329 .cfm pages, 161 configured Transfer Objects, 40 MachII frameworks instances (we started this before modules), and 201 Tables.  This actually results in about 22,000 .class files being generated by ColdFusion behind the scenes.

What we began to experience is extremely long start up times when the server was first started up. For example with no class files saved on the server, we have a start time of around 20 minutes before the application was responsive, and if multiple people hit the site at once, we were looking at around 45 minutes before the application would perform usably.

With class files saved, this dropped down to 9 minutes, but we still ran into huge difficulties with multiple users hitting the site at once.  On top of that, whenever we had to upload a change, clearing the template cache so the change would propagate brought the server to it's knees, so we were forced to restart CF with every deployment of code.

So after much haranguing, and talking to a whole slew of people, both Adobe, and non Adobe (you all know who you are, and thank you very much for the time and effort you all put into helping out on this), it eventually got narrowed down to a bottleneck in Java 6 as described here (as also reported by Sean Corfield )

So for those of you not so familiar with Java, what does all that actually mean?  Well, let's look at what ColdFusion does behind the scenes when you run a .cfm or .cfc page:

  1. Checks to see if it has the Java Classes already in memory to do what you have requested - if not,
    1. CF Reads in the file you are executing
    2. Parses the CFML
    3. Converts the parsed CFML data structure, and converts it into Java code
    4. Compiled that Java code down to actual Java .class files
    5. Loads the resulting .class file into memory
  2. Executes the Java code contained in the .class file as necessary.

So probably nothing too revolutionary in there in terms of our understanding of the ColdFusion process, however, there is a big bottle neck in Java 6 where the loading into memory Java classes is really really really slow (maybe I need another really there), so step 1.5 on the above processes takes a very long time to get through - and the problem only gets worse when there are large numbers of very small classes - which in almost any ColdFusion application, and ours in particular, there are.

There are several places in which this issue can cause serious problems -

  1. At System Start Up
    As discussed previously.

  2. Development.
    Obviously during development, files tend to change quite regularly.  During development of our application, it would not be strange for me to be spending several minutes, to the tens of minutes waiting for a small change in either a .cfm or .cfc to come through. This simply slows down the amount of work that you are able to do in any given time frame.

  3. At Run Time
    Since ColdFusion has a finite limit on the number of cached templates (which are just the .class files mentioned earlier stored in memory), it is quite likely that at some point during an application life cycle, part of what is stored in the template cache will get purged so as to make room for other Java classes that have become active.  We hit the same issue as we hit on step 1.5 as above, as the ColdFusion server slows down as it pulls in the required Java classes into memory.  This can result in random slowdowns in the application, which are hard to reproduce.

    This becomes a larger issue on shared host systems, in which a trusted template cache is impossible, and it is quite likely the ColdFusion server is constantly moving the generated Java code in and out of it's template cache, as multiple systems require different ColdFusion code to be executed.

It wasn't until we had one of those head-slap moments when a co-worker turned around to me and said 'well.. why don't we try Java 1.5?'?

Once installed, suddenly everything started working like we wanted it to, performance wise.

Since everyone loves a pretty graph, here are some metrics on server start up, taking a Selenium script through a series of steps through one part of our application, so you can see the considerable difference between the two Java Versions

Average TIme Taken

Total Time Taken

Not only has this made our production systems run incredibly fast, it also means that we are able to upload code to the production server, clear the template cache, clear the application cache, and we are good to go, there is no need to restart ColdFusion for changes.

This also means I can develop without having to take a coffee break in between code changes, which has upped my productivity as well, in fact, I can now develop happily in Machii with the config mode set to constantly reload, and performance is no problem at all.

As far as I am aware, this issue does not exist in the development snapshots of Java 7, and apparently a fix is in the pipeline for 1.6, but Sun hasn't been forthcoming about the date.

Until that time, I would suggest moving your ColdFusion 8 servers over to Java 1.5, and enjoy the speed improvements!!!

Comments

Posted by Michael Sharman on 06 December 2007 10:15 PM

Hi Mark,

Understand that you get improvements on startup (or any CF files which haven't been compiled to .class files) but what about after that. I mean the 'general' running of CF on 1.6 vs 1.5, would you see slower performance on 1.5?

Posted by Will B. on 06 December 2007 11:25 PM

I'm good at CF, but no so much on configuration management. Is there a tutorial or something somewhere that explains how to do this switching from J7 to 1.5? (Sounds like going backwards...! Someone explained a while back to me about weird version numbering, though.)

Posted by Mark on 07 December 2007 07:36 AM

@Michael
The general run time of 1.5 vs 1.6 once classes were loaded into memory was almost identical. But, to reiterate, you don't get the random slowdowns on 1.5 where classes are loaded back into memory at run time.

@Will
http://www.forta.com/blog/index.cfm?mode=entry&entry=A61BAA93-3048-80A9-EF7306C155FD29F4

Posted by Stefan on 18 May 2008 11:55 PM

Just wanted a little update about this issue. Are you guys still running 1.5 or is the problems fixed in newer versions of Java 1.6? I am running a CF system that has more 100 hits/second at peaks and about 50 hits/second in average and have so far been running the system for a long time without any glitches. But the traffic goes up and it is becoming incresingly difficult to get the system up after adding new code or similar. The site is almost exlusively cfc's and cached objects, so when it crashes, it crashes bad...

Thanks

Posted by Mark on 19 May 2008 04:46 AM

@Stefan - still running 1.5. The bug fix required is meant to be coming in 1.6 update 10.

Posted by Brian G on 15 June 2008 03:06 AM

1.6u10 is in beta now: http://java.sun.com/javase/downloads/index.jsp

Posted by John Scott on 10 July 2008 10:10 AM

We are experiencing the same problem with our MachII application that we want to migrate to CFMX6.1 to CF8. Looks like Java 1.6u10 is still in beta so we will wait until the release version arrives before we try it. Reverting to Java 1.5 has solved the problem for us too and we are presently using that.

Posted by Mark on 10 September 2008 09:52 AM

We're having the same random slowness issues running CF 8.01 on Linux (Cent OS)/JBOSS/Apache with Java version 1.5.0_16. Any chance backing down to 1.5.0_14 would help us at all? Anyone else out there running CF on JBOSS? Any possibility that this would cause us any of these problems?

Posted by Brian on 10 September 2008 10:00 AM

Mark - I would instead advise you to move up to 1.6.0_10 which fixes this problem. u10 has been in beta for a loooong time and is very stable. Check my blog: http://www.ghidinelli.com/2008/08/18/java16-u10-gives-big-boost-to-modelglue-transfer-coldspring-performance

Posted by Pat Branley on 18 December 2008 01:23 PM

Mark, whats the latest on this issue ? does 1.6.0_10 solve it or is 1.5 still a good option ?

Posted by Mark on 18 December 2008 01:29 PM

@Pat -
I would recommend moving up to the latest JVM, I believe its update 11 now. It should be far more performant that 1.5, and solves the issue with the original 1.6 JVM.

Posted by Aurelien on 02 April 2009 08:05 PM

Hello Mark -

I've followed this advice by upgrading my JVM to the 1.6.0_11.

Until this point (reproduced on two servers) all cfform type Flash doesn't work. CFchart doesn't appear either.

I've rooled back to the original jvm, and the problem is still there.

Any idea ?

Thanks,
Aurelien



Posted by Mark on 03 April 2009 08:11 AM

@Aurelien, I haven't heard that one before. What error message are you getting?

It may be worth running CF via a command console, so you can see if there is any debug errors there.

Add Comment