Entrevista a Kirk Pepperdine (java champion) acerca de Performance Tuning
miércoles, julio 23, 2008 at 12:35PM Janice J. Heiss continua la serie de entrevistas que Sun ha venido haciendo a los Java Champions, con esta conversación con Kirk Pepperdine, principal contribuidor del sitio javaperformance.com
En la conversación Kirk menciona asuntos generales sobre cómo mejorar el desempeño de las aplicaciones Java, pero en vez de dar tips concretos nos brinda consejos que nos ayuden a encontrar más fácilmente los cuellos de botella de nuestras aplicaciones.
El primer consejo es "mide, no adivines" y trata de que no se debe actuar hasta no tener medidas sólidas que nos ayuden a detectar el problema directamente. Tener estas medidas puede no ser fácil, sobre todo teniendo en cuenta que las personas a menudo trabajan con sobre entendidos.
Es aquí que viene el segundo consejo: la caja:
Que simplemente es una guía para investigar problemas y sirve para recordarnos que una aplicación es más que software, involucra a la gente, al hardware y -en el caso de java- a la JVM.
Otro tema que toca Kirk en la conversación son las ideas equivocadas que tenemos sobre el performance tunning. Menciona que en su trabajo como experto en el tema, a menudo el gerente le pone un ordenador con el código de la aplicación y espera que en una semana haya resuelto los problemas de performance. Este tipo de personas se sorprende cuando él ni siquiera revisa el código y se dedica a medir con herramientas como los profilers el desempeño para poder detectar los problemas. Resulta interesante también que menciona que en los cursos que da, el primer tema es resolver el problema de desempeño de una aplicación auxiliándote de un profiler en 30 minutos; sin embargo los programadores nunca pueden hacerlo porque al tener el límite de tiempo se van directo sobre el código fuente a aplicar lo que ellos piensan son optimizaciones. De acuerdo a Kirk, las personas que han podido resolverlo en el tiempo dado, son todos testers que al no tener tantos conocimientos sobre Java, deciden usar primero el profiler y solo entonces tocar el código.
Sobre el tema de mejorar el desempeño de acceso a la base de datos, menciona que es invaluable tener la ayuda de un DBA en este aspecto y que a menudo se consigue el objetivo mediante las técnicas propias de las bases de datos relacionales: disminuir el número de joins, creación de índices, etc.
Otro punto importante es usar cache, si usas un ORM este punto puede ser simple de implementar. Sin embargo si has hecho cosas como poner mucha lógica de negocio en la base de datos (supongo que en forma de stored procedures) usar un cache es mucho más complicado sin tener que rescribir tu código.
Copio y pego estos consejos de Kirk: "... el primer paso para reconocer la sobreutilizaciónn es contar el número de interacciones entre la aplicación y la base de datos. Esta cuenta debe ser confrontada conhtera el trabajo que la aplicación realiza. Existen herramientas que te permiten hacer medir esto. Glassbox y JaMon son un par de herramientas opensource. La mayoría de los fabricantes comerciales también las ofrecen. El quick fix es añadir cache, ya que es mucho más fácil hacer esto que eliminar llamadas excesivas a la base de datos. Aquí hay un consejo para llevar: la llamada más barata que puedes hacer es la que no haciste".
Sobre optimizar el consumo de memoria Kirk menciona tres casos:
- Memory leaks: los más sencillos de detectar y resolver, gracias al uso del profiler de Netbeans o de VisualVM.
- Objetc Loitering: este término se refiere a los objetos que ya no están siendo usados y deberían de ser recolectados por el GC pero no lo son. Kirk menciona que ahora son sencillos de detectar gracias a una nueva funcionalidad en el profiler de Nb (llamado generations).
- Object churn: un término que se refiere a un estado en que la JVM se dedica a crear y recolectr objetos con el GC. Si el tiempo dedicado a esto es demasiado alto, te provocará un mal desempeño. Kirk recomienda monitorizar el comportamiento del GC para detectar estos problemas, que se pueden resolver de forma simple ajustando el tamaño del Heap.
Esta entrevista me ha gustado mucho y creo que los tips que da son invaluables para todos nosotros que nos dedicamos a desarrollar con java, no se pierdan la entrevista completa en inglés que sin duda tiene más información de la que yo pude resumir aquí.
j2se 
Reader Comments