portal entry

Does CF11 perform better with UseG1GC or useparallelgc?

Comment by Jose Gosende

Hi Jose, Hard to say without enabling Java logging or management extensions (JMX), then read the log output or use Mission Control (JMC) to compare results. Performance could be effected if there are long pauses by full garbage collections. I have seen some CF11 Java 8 perform better with G1 vs Parallel and I have seen some perform worse. With CF11 Java 8 it is possible to use ConcMarkSweep and ParNew together which might perform better vs say either G1 or Parallel. There can be other things that have impact on performance like the CFML (application code) or speed of database access. Sometimes JMC can be useful to use to know if tomcat threads are taking a long time to respond which is indicative of CFML or database slowness. There are other vendor tools available to check on parts of CF11 performance like CFs own Server Monitoring if you have Enterprise edition. Note: Java 9 depreciated ConcMarkSweep and ParNew. So for CF2018 with Java 10 ConcMarkSweep and ParNew are not available. Regards, Carl

Comment by Carl Meyer

Thanks for pointing out for folks the change in java 10's g1gc, Carl. I will be very interested to hear if it truly makes an observable difference for most over how g1 worked before, or even indeed over the parallel gc. In my experience, gc choices and even gc "tuning" (other than heap or metaspace/permgen max sizes) are not the cause or even the best solution for most performance problems. Rather, high heap use is usually solved by addressing whatever is using it unexpectedly (or raising the max, but not too high to cause long pauses). And on a related but separate matter, high metaspace/permgen use is most often solved by proper sizing of the CF admin template cache size (or, again, simply raising that memory space's max--or outright removing maxmetaspacesize in Java 8 and up, as then it is unrestricted in size). So I was very glad to see you mention doing logging and analysis. That could help one know if they have any gc problem to begin with (in terms of unexpected pauses), and if addressing the real root cause of any gc problem helped or not. If, then, it turned out that changing the gc algorithm alone really solved a problem, that would indeed be very interesting to hear. I will add, for those coming across this and perhaps facing performance challenges, I understand how gc tuning has often been touted as the possible solution to such problems. As Carl has indicated, getting gc logging is a place to start to see if that would help. But you need not stop there. You could also use jvm tools to obtain thread dumps and do heap analysis or profiling. Or you can use tools created for CFers that facilitate doing some or all of those things, and even more. In cf8-2016 enterprise, we have the CF server monitor. In cf2018 (standard or enterprise edition) we have the new performance monitoring toolkit. And in all cf editions and versions (old and new) we have FusionReactor and SeeFusion. All these are much more focused on request processing than are jvm tools. They can be easier to use, as well. Indeed,FusionReactor's Ultimate edition adds classic jvm tools like heapndumps, profilers. And step debugging all via a web interface-- no IDE or jmx needed. Carl's conclusion is on point. Anyone debating gc changes as a solution needs to use tools to a) know their problems or b) know if any change has helped (or hurt). I will say also that there are folks who can help with such troubleshooting and tunig. See my list of cf troubleshooting consultants (including myself) at https://www.cf411.com/cftrouble. HTH

Comment by Charlie Arehart

<strong>2019 ??? ????? ??? ????? ???????? ?? Pro Team NW ??? ????? ????? ?????? ????? ????? ?????? ?? ????? ??????? ?????? ????? ???? ????????</strong> under armour swimsuit custom camera jumbo speaker yellow champion sweatpants nike golf apparel outlet deering goodtime banjo 915 denier cordura big thermos nike cheer shorts coque samsung s6 plus etui samsung a3 2017 cadre m?tallique samsung galaxy s4…

Comment by Anonymous