java - servidores - wildfly 11
Rendimiento del servidor de aplicaciones Java (2)
SunONE en sí mismo es un dolor en el culo. Tengo el mismo problema, ¿y sabes qué? Una simple redistribución de la misma aplicación a Weblogic redujo el consumo de memoria y el consumo de CPU en aproximadamente un 30%.
SunONE es un servidor de implementación de referencia y no debe utilizarse para la producción (no sé sobre Glassfish).
Lo sé, esta respuesta realmente no ayuda, pero he notado pausas considerables incluso en operaciones muy simples, como obtener una instancia de bean de un grupo.
Puede ser, ¿intentar implementar JBoss o Weblogic en la misma máquina podría darte una pista?
PD: No debe mostrar contenido estático desde el servidor de aplicaciones (aunque a veces también lo hago cuando la CPU es abundante).
Los usuarios simultáneos de PPS 500 tienen una carga bastante alta, definitivamente pondría SunONE detrás de un proxy de almacenamiento en caché o Apache que sirve contenido estático.
Tengo una aplicación Java EE algo anticuada ejecutándose en Sun Application Server 8.1 (también conocido como SJSAS, precursor de Glassfish). Con más de 500 usuarios simultáneos, la aplicación se vuelve inaceptablemente lenta y estoy tratando de ayudar a identificar dónde se gasta la mayor parte del tiempo de ejecución y qué se puede hacer para acelerarlo. Hasta ahora, hemos estado experimentando y midiendo con LoadRunner, los registros del servidor de aplicaciones, Statpack de Oracle, snoop, ajustando el aceptador del servidor de aplicaciones y los hilos de la sesión (trabajador), ajustando el tamaño de lote de Hibernate y uniéndose al uso de recuperación, etc. pero después de algunas ganancias iniciales estamos luchando para mejorar las cosas más.
Ok, con esa introducción al problema, aquí está la verdadera pregunta: si tuvieras una aplicación lenta de Java EE ejecutándose en una caja cuyo uso de CPU y memoria nunca fuera superior al 20% y mientras corrías con más de 500 usuarios mostraste dos cosas: 1) que solicitar incluso archivos estáticos dentro del mismo proceso de JVM del servidor de aplicaciones era extremadamente lento, y 2) que solicitar un archivo estático fuera del proceso de JVM del servidor de aplicaciones, pero en el mismo cuadro era rápido, ¿qué investigarías?
Mis pensamientos saltaron inicialmente a los hilos del servidor de aplicaciones, tanto del aceptador como de la sesión, pensando que incluso las solicitudes de archivos estáticos estaban en cola, esperando un hilo disponible, y si la CPU / memoria no estaba realmente gravada, entonces había más hilos en orden. . Pero luego aumentamos sustancialmente tanto el aceptador como los hilos de sesión y no hubo mejoría.
Ediciones de clarificación:
1) Los archivos estáticos deben ser servidos por un servidor web en lugar de un servidor de aplicaciones. Estoy usando el hecho de que en nuestro caso esto (desafortunadamente) no es la configuración, así que puedo ver el rendimiento del servidor de la aplicación para los archivos que no ejecuta, excluyendo los costos de rendimiento de la base de datos, etc.
2) No creo que exista un proxy entre los solicitantes y el servidor de aplicaciones, pero incluso si lo hubiera no parece estar sobrecargado porque los archivos estáticos solicitados desde el mismo servidor de aplicaciones pero fuera de la instancia de JVM de la aplicación regresan inmediatamente .
3) El tamaño del almacenamiento dinámico de JVM (Xmx) está establecido en 1 GB.
¡Gracias por cualquier ayuda!
Después de usar una herramienta de supervisión del rendimiento de Sun, descubrimos que el recolector de basura se estaba ejecutando cada dos segundos y que solo se usaban aproximadamente 100 MB del montón de 1 GB. Así que tratamos de agregar las siguientes opciones de JVM y, hasta el momento, esta nueva configuración ha mejorado mucho el rendimiento.
-XX: + DisableExplicitGC -XX: + AggressiveHeap
Ver http://java.sun.com/docs/performance/appserver/AppServerPerfFaq.html
Nuestra lección: no deje ajustes de opciones de JVM y ajustes de recolección de basura al final. Si tiene problemas de rendimiento, mire estos ajustes al principio de su proceso de solución de problemas.