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:
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í.
Etiquetas: j2se, performance
Respecto a las herramientas de Netbeans: a mi me ha resultado especialmente útil el profiler, para encontrar un problema de Object Loitering (la primera vez que veo que se le llama asi). Como referencia dos artículos me ayudaron:
http://www.netbeans.org/kb/articles/nb-profiler-uncoveringleaks_pt1.html
http://www.netbeans.org/kb/55/profiler-tutorial.html#Exercise_3
La verdad no sé que hubiera hecho sin el profiles. Muy, pero que muy interesante la noticia.
Salu2
[advertencia: comentario pijotero-pedante]
Se dice 'tuning', con una sola 'n'.
Lo siento, no me pude aguantar.... :-)
listo, gracias por la corrección
El problema es que al cambiar el titulo del artículo ha cambiado el enlace y todos los que ya habian enlazado (blogs, fuentes rss, etc) tienen un enlace que ahora es erroneo.
Mmm interesante articulo, lo leere completo a penas tenga tiempo. Sobre los profiles, realmente son unas maravillas del software, el de netbeans me ha resuelto problemas graves pero todavia me falta utilizarlo mas y aprender algunas cosillas. Leere tambien los enlaces de Ibon. Lo que comenta el autor sobre medir en vez de adivinar es la verdad mas cierta que he escuchado en estos dias, y es muy facil tender a suponer cosas y toquetear codigo sin nisiquiere tener un margen de seguridad que te diga que es lo que esta fallando..
Yo nose si a alguien le ha pasado. Pero puedo decir que el proyecto que estoy haciendo actualmente esta un 30% desarrollado por todos ustedes y por otras comunidades como Javahispano pero especificas a algun framework. "Que orgulloso me siento de haber nacido en mi tierra" (como dice la cancion, tierra = java)
Ummm, profilers, uso de Caches, contar un con DBA para optimizar la BD... donde habre oido yo esto ultimamente :).
Algo que tambien comenta y no veo reflejado en el resumen es que un error que cometen muchos programadores es escribir código muy complejo para intentar aumentar el rendimiento usando trucos ocultos etc. cuando en realidad los "programadores" que más saben de trucos son el compilador y el JIT, y en muchos casos escribir codigo "directo" o "no listillo" facilita que puedan hacer optimizaciones y el resultado puede ser más rapido y encima el código es más claro.
Kirk tiene un poco pinta de cientifico loco, pero sabe un montón. Claro que a veces los casos de los que habla no los tenemos nosotros todos los dias, como tener un sistema con miles de nucleos (cores) etc. :)
Ummm, profilers, uso de Caches, contar un con DBA para optimizar la BD... donde habre oido yo esto ultimamente :).
De javu. ¿escuchastes algo parecido o es el mismo gato negro??
No se...
javaHispano: Artículo sobre cómo escalar aplicaciones Java EE
¿Hay cuchara? :)
hahah :D
Escribe tu comentario