java coldfusion java-7 coldfusion-10

Coldfusion 10 más lento cuando se usa Java 1.7 en comparación con 1.6



java-7 coldfusion-10 (2)

Tengo un servicio web ejecutándose en Coldfusion 10 64bit . Mientras investigaba una pérdida de memoria, fui a actualizar el JRE de 1.6 a 1.7, pero noté un impacto significativo en el rendimiento. Había creado un servicio web de prueba simple que en JRE 1.6 podía ejecutar fácilmente a 5000 solicitudes por minuto tan pronto como cambié el JRE a 1,7, aunque esta tasa se redujo también a 2000 o menos por minuto. ¿Alguien sabe de ajustes de sintonía o algo que me estoy perdiendo?

La preferencia es usar JRE 1.7 ya que parece haber solucionado el problema de pérdida de memoria que estaba teniendo.

  • Ejecutando el servidor JRE: versión de Java "1.7.0_51" Java (TM) SE Runtime Environment (compilación 1.7.0_51-b13) Java HotSpot (TM) VM de servidor de 64 bits (compilación 24.51-b03, modo mixto)

  • Recolección de basura en la configuración de JVM: -XX:+UseParallelGC

  • Cambió la recolección de basura a: -XX:+UseG1GC esto no hizo ninguna diferencia.

Seguí las recomendaciones desde aquí sin ningún aumento en el rendimiento. Lo revisaré con jvisualvm y publicaré mis conclusiones.

Actualización: Java 7 ha cambiado la forma en que trata la sincronización de los cargadores de clases y parece que esto puede ser la causa de la desaceleración.

La actualización Adobe ha reconocido el error y está tratando de solucionarlo. Registro de base de errores de Adobe.

Le recomendaría que revise los datos del volcado de subprocesos de la JVM entre sus 2 ejecuciones de prueba de carga (JRE 1.6 vs. JRE 1.7). He visto problemas con el cargador de clases CF10 en el pasado asociados con el uso de cfdump y cfquery en memoria (consulta de consultas).

Concentre su análisis en cualquier problema de contención de bloqueo de subprocesos que pueda enfrentar con JRE 1.7.

Se supone que el cambio del cargador de clases al que se refiere debe mejorar la concurrencia de las operaciones de carga de clases, pero aún así no es imposible que pueda desencadenar cierta lentitud en su entorno.

Otra recomendación es mirar la tasa de asignación de memoria de tu GC. Para este propósito, active verbose: gc y compare los datos de salida entre sus 2 ejecuciones. Determine si algún aumento en la tasa de asignación de memoria del GC y / o la frecuencia del GC podría ser la causa principal de esta caída de rendimiento.

Finalmente, realice una revisión muy cercana de los argumentos de JVM. Asegúrese de que los argumentos de ajuste de la pila de Java, incluido el tamaño de la pila, sean exactamente iguales a los de JRE 1.6 para que podamos comparar manzanas con manzanas.