Si estás usando Java 1.4.X como máquina virtual para correr JRUN, lo tienes complicado. La monitorización a través de JMX en esta versión de la máquina virtual es muy limitada, no podrás ver información de consumo de memoria ni uso de threads.

Si es posible deberías plantearte la migración a Java 1.5 (o mejor aún 1.6), no sólo por temas relacionados con la monitorización, también existen mejoras de rendimiento, bugs solucionados y mejoras funcionales incluidas en versiones posteriores a Java 1.4.

En cuanto la configuración de JRUN, siento decirte que no tengo experiencia con este servidor, me muevo en un entorno más orientado al Open Source. En cualquier caso supongo que JRUN debe tener un script de arranque, comienza mirando por ahí, busca la variable JAVA_OPTS. Pero como te comento, con Java 1.4 no obtendrás los datos que esperas de JConsole.

Un saludo.

En mi caso tengo un servidor con J2RE1.4.2_01 y un JRUN 4 instalado. La aplicación corre bajo el servidor JRUN y desconozco cómo hacer que la JVM cargue estos parámetros para poder conectarme de forma remota con la JConsole (que la tengo en otro servidor con el JDK).

¿Quizá tenga una versión de JRE antigua?
¿Hay que configurarlo en el servidor de JRUN?
¿Si instalo JDK en el servidor para poder tener la JConsole , podría tener algún problema?

Gracias

Efectivamente, JDK 1.5 (que no JRE) también se incluye.

El “porqué” es el objetivo final, normalmente lo obtenemos en base a un compendio de datos (análisis estático del código, la propia monitorización, y en casos más duros haciendo profiling, mirando en qué partes del código está más tiempo la línea de ejecución y analizando el código en cuestión). Eclipse MAT tiene buena pinta, habrá que probarlo.

Por supuesto, JMeter es una buena opción. He apostado por “The Grinder” porque me ha parecido muy versátil (la posibilidad de poder distribuir el script de pruebas y los ficheros de configuración a los agentes al vuelo) y sobre todo por la potencia que proporciona el poder ejecutar un script Python (Jython en realidad) pudiendo hacer uso de cualquier funcionalidad que puedas conseguir con Python. Esto no hace que JMeter deje de ser interesante ;-) , y la madurez es un punto a su favor.

Un saludo, y gracias por el comentario!

Lo siguiente es… porqué. Y eso ya es más dificil. Para los casos de consumo de memoria excesivo, me ha sorprendido lo bien que funciona Eclipse MAT (eso si, hay que acordarse de lanzar la aplicación con -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/para/volcados).

Sobre la mención a herramientas para pruebas de carga, añadir JMeter. Es software maduro (y quizá poco interesante ;-) ), pero hace prácticamente de todo (muy similar a The Grinder).

En cuanto al rendimiento, según comenta Eamonn McManus (developer lead de JMX), no debe suponer más de 5-6 %. No es mucho, pero hay que tenerlo en cuenta.

Un saludo.

Genial, veo que estás resolviendo la parte que el otro día nos faltaba. Conocer qué le pasa en el servidor mientras lanzamos las pruebas. Desde el cliente es fácil, ya “sufrimos” los resultados pero ahora puedes ver cuánto “sufre” el servidor.

Dado que estas usando JMX, no olvides citarlo en tus conclusiones. Ese método, aunque es de los menos intrusivos, afecta al rendimiento.

Buen trabajo.