Coldfusion 10 slower when using Java 1.7 compared to 1.6

Question

I have a webservice running on Coldfusion 10 64bit. While investigating a memory leak I went to upgrade the JRE from 1.6 to 1.7 but noticed a significant performance hit. I had created a simple test webservice which on JRE 1.6 I could run easily at 5000 requests per minute as soon as I changed the JRE to 1.7 though this rate drops too 2000 or less per minute. Does anyone know of tuning settings or something I am missing.

The preference is to use JRE 1.7 as it appears to have fixed the memory leak issue I was having.

• Running Server JRE: java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)

• Garbage Collection in JVM settings: -XX:+UseParallelGC

• Changed Garbage Collection to : -XX:+UseG1GC this made no difference.

Followed the recommendations from here with no increase in performance. Will review with jvisualvm and post my findings.

Update: Java 7 has changed the way it deals with synchronizing class loaders and it looks like this may be the cause of the slowdown.

Update Adobe has acknowledged the bug and is looking to fix it. Adobe bug base record.

Answer 1

Answer for this is that Adobe has acknowledged the bug and is looking to fix it. Adobe bug base record.

Answer 2

I would recommend that you review the JVM Thread Dump data in between your 2 load testing runs (JRE 1.6 vs. JRE 1.7). I have seen CF10 class loader issues in the past associated with the usage of cfdump and cfquery in-memory (query of queries).

Focus your analysis on any thread lock contention problem that you may be facing with JRE 1.7.

The class loader change you are referring to is supposed to actually improve concurrency of the class loading operations but still not impossible that it may trigger some slowness in your environment.

Another recommendation is to look at your GC memory allocation rate. For this purpose, turn on verbose:gc and compare the output data between your 2 runs. Determine if any increase of the GC memory allocation rate and/or GC frequency could be at the root cause of this drop of throughput.

Finally, perform a very close review of the JVM arguments. Ensure that your Java heap tuning arguments, including heap sizing are exactly the same as per JRE 1.6 so we can compare apples vs. apples.