Encuesta

¿Qué servidor de aplicaciones empleas mayormente para despliegue?

01-10-2008 - 306 votos

Destacados Agenda

Más eventos |

(1)

Entrevista a Kirk Pepperdine (java champion) acerca de Performance Tuning

23/07/2008 12:24 ecamacho

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:

/contenidos.downloadimg.action?id=2857436

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í.

Volver a actualidad

Etiquetas: j2se, performance

Comentarios: 9

  • ibon 23/07/2008 12:48

    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

  • jhernandez 23/07/2008 13:20

    [advertencia: comentario pijotero-pedante]

    Se dice 'tuning', con una sola 'n'.

    Lo siento, no me pude aguantar.... :-)

  • ecamacho 23/07/2008 14:21

    listo, gracias por la corrección

  • jfisbein 23/07/2008 14:59

    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.  

  • Marioko 23/07/2008 15:45

    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)

  • greeneyed 23/07/2008 18:36

    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. :)

  • Marioko 23/07/2008 19:14

    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??

  • greeneyed 23/07/2008 20:37

    No se...

    javaHispano: Artículo sobre cómo escalar aplicaciones Java EE

    ¿Hay cuchara? :)

     

     

  • Marioko 23/07/2008 20:42

    hahah :D

Escribe tu comentario

Sun Microsystem Logo NHT-Norwick Logo

© 2002-2007 Asociación javaHispano