java - tutorial - visualvm remote
No puedo ver mis propios métodos de aplicación en Java VisualVM (3)
Podría echar un vistazo a Appdynamics Lite, tiene una gran variedad de funciones, como el descubrimiento de transacciones comerciales, que puede mostrar todas las llamadas realizadas a un método específico en su código.
La versión Lite tiene muchas limitaciones, como un máximo de muestreo de 10 minutos y un máximo de 30 transacciones comerciales.
Sería bueno tener herramientas gratuitas que hagan lo mismo.
Estoy tratando de crear un perfil de mi aplicación java, solo para descubrir los métodos en los que se gasta más tiempo. Dadas las malas reacciones aquí a TPTP, pensé en probar Java VisualVM.
Todo parecía bastante simple de usar, excepto que parece que no puedo obtener nada coherente o útil.
Parece que no puedo ver nada relacionado con el código MY OWN, todo lo que recibo es un montón de llamadas a cosas como los métodos java. *.
He intentado restringir la instrumentación solo a mis propios paquetes, lo que parece reducir la cantidad de métodos instrumentados, pero aún así parece que nunca veo los míos.
Cada vez que corro, obtengo un número variable de métodos instrumentados, que van desde los 10 a los 1000. He intentado poner en suspensión al inicio de mi aplicación, para asegurarme de que VisualVM esté funcionando antes de que la aplicación comience a hacer algo interesante, para asegurarme de que se está perfilando cuando se está ejecutando lo interesante.
¿Hay algo que deba hacer para asegurar que mis clases se instrumenten? ¿Hay problemas de tiempo? ... como, ¿hay que esperar a que se carguen las clases, etc.? También he intentado ejecutar las agallas del código dos veces, para asegurarme de que se ejecute todo el código ...
Solo estoy ejecutando una aplicación, con un main, de Eclipse. He intentado usar la integración de Eclipse para que VisualVM se inicie cuando inicio la aplicación; los resultados son los mismos. También he intentado exportar la aplicación como una aplicación ejecutable y ejecutarla de forma independiente desde la línea de comandos, en lugar de hacerlo a través de Eclipse: el mismo resultado.
Mi aplicación no es una aplicación web de larga duración, etc., solo una aplicación principal que llama a algunas de mis propias clases para que realicen un procesamiento y luego se cierran.
¡Le agradecería cualquier consejo sobre lo que podría estar haciendo mal! :)
Gracias !
Supongo que esto no es solo una pregunta académica; le gustaría ver si la aplicación se ejecuta más rápido. Supongo que a usted tampoco le importaría pensar un poco "fuera de la caja". Hay muchas ideas populares sobre el rendimiento que en realidad son bastante difusas.
Por ejemplo, usted dice que está buscando "métodos en los que se gasta más tiempo". Si con eso te refieres a "self time" (programa contador en realidad en el método) probablemente hay muy poco, a menos que tengas algunos bucles intensos. Los métodos generalmente pasan tiempo llamando a otros métodos, a veces haciendo E / S.
Otra idea confusa es que medir el tiempo del método o contar el número de llamadas puede decirle mucho sobre dónde están los cuellos de botella. Los cuellos de botella son líneas de código específicas, no métodos, por lo que incluso si sabe aproximadamente dónde buscar, todavía está jugando al detective.
Así que esas son algunas de las ideas difusas. Aquí hay un montón más. Permítanme sugerir cómo se debe pensar en ello y cómo eso lleva a los resultados.
Cuando finalmente arregles algo, reducirá el tiempo de ejecución en algún porcentaje, como (elige un número) 30%, ¿verdad? (De lo contrario, no arreglaste nada). Bien, durante ese 30% estaba haciendo algo, algo que no tenía que hacer porque más tarde te deshiciste de él. Por lo tanto, no es necesario medir. Es necesario que averigüe qué está haciendo en ese momento, para saber de qué deshacerse.
Una forma muy simple es "pausar" 10 veces (o un número de veces) al azar. Entienda lo que está haciendo y por qué, mirando la pila de llamadas y posiblemente algunos de los datos. Aproximadamente 3 de esas veces lo verás haciendo algo de lo que podrías deshacerte.
Sabrá aproximadamente cuánto ahorrará al ver qué porcentaje de muestras lo muestra. Lo aproximado es lo suficientemente bueno. Puede ver fácilmente cuánto tiempo se ahorra con cronómetro antes y después.
Entonces, no te detengas. Has hecho la aplicación más rápida. Hazlo de nuevo, y hazlo más rápido todavía. Tarde o temprano llegas a un punto en el que no puedes hacerlo más rápido, pero probablemente esté en más de un paso.
Yo también estoy luchando con VisualVM, lo cual es una pena porque su interfaz de usuario es fantástica, mientras que su salida de perfiles parece horrible. Puede parecer mi pregunta aquí.
Puedo decirles un par de cosas extrañas que he aprendido sobre VisualVM y la forma en que parece hacer su perfilado.
VisualVM parece estar contando el tiempo total pasado dentro de un método (tiempo de reloj de pared). Tengo un subproceso en mi aplicación que inicia un número de otros subprocesos y luego bloquea inmediatamente la espera de un mensaje en una cola. VisualVM no registrará este método en el generador de perfiles hasta que uno de los otros subprocesos envíe el mensaje que estaba esperando el primer subproceso (cuando finaliza la aplicación). De repente, la llamada al método de bloqueo domina la salida del perfilado y se registra que ocupa más del 80% del tiempo de aplicación.
Otros perfiladores, como JProfiler y el usado por Azul, no cuentan un hilo bloqueado como el tiempo que ocupa el perfilador. Esto significa que los métodos de bloqueo que probablemente no sean interesantes (dependiendo de la situación) para el perfil de rendimiento están ocultando su visión del código que está consumiendo su tiempo de CPU.
Cuando estoy ejecutando mi perfilado termino con
sun.rmi.transport.tcp.TCPTransport $ ConnectionHandler.run ()
ocultando mi perfil hasta que el mensaje vuelve al hilo de espera y luego se comparte el primer lugar entre estos dos métodos totalmente irrelevantes, así como otros métodos no interesantes que no aparecen en otros perfiladores.
En segundo lugar, y creo que es muy importante que el mecanismo de filtrado de métodos no funcione como esperaba. Esto significa que no puedo filtrar lo que estoy tratando de encontrar en este momento.
No es una respuesta realmente útil. La solución tal como la veo ahora es pagar por JProfiler: VisualVM no parece confiable para esta tarea.