2009-04-24 6 views
5

Tengo una aplicación de código abierto de Java que utiliza Hibernate y HSQLDB para la persistencia. En todas mis pruebas de juguetes, las cosas corren rápido y todo está bien. Tengo un cliente que ha estado ejecutando el software durante varios meses continuamente y su base de datos ha crecido significativamente durante ese tiempo, y el rendimiento ha disminuido gradualmente. Finalmente se me ocurrió que la base de datos podría ser el problema. Por lo que puedo decir de las instrucciones de registro, todo el cálculo en el servidor ocurre rápidamente, por lo que esto es consistente con la hipótesis de que el DB podría tener la culpa.Cómo ajustar el rendimiento de la aplicación hsqldb/hibernate

Sé cómo hacer un perfil normal de un programa para descubrir dónde están los puntos calientes y lo que está ocupando una cantidad significativa de tiempo. Pero todos los perfiladores que conozco monitorean el tiempo de ejecución dentro del programa y no le doy ayuda acerca de las llamadas a recursos externos. ¿Qué herramientas usan las personas para perfilar los programas que usan llamadas de db externas para averiguar dónde optimizar el rendimiento?

Una pequeña búsqueda a ciegas ya ha encontrado algunos puntos calientes: noté una llamada en la que enumeraba todos los objetos de una clase en particular para ver si había alguno. Un cambio de una línea al criterio [.setMaxResults (1)] cambió esa llamada de medio segundo a virtualmente instantánea. También veo lugares donde hago la misma pregunta desde el DB muchas veces en una sola transacción. Todavía no he resuelto cómo guardar la respuesta en caché, pero lo que realmente quiero es una herramienta que me ayude a buscar este tipo de cosas de forma más sistemática.

Respuesta

3

Desafortunadamente, hasta donde yo sé, no hay ninguna herramienta para eso.

Pero hay algunas cosas que usted puede comprobar:

  • ¿Está utilizando la carga ansiosa lugar de carga diferida? Por la descripción de su problema, realmente parece que no está utilizando la carga diferida ...
  • ¿Ha encendido y configurado correctamente el almacenamiento en caché de segundo nivel? ¿Incluyendo el caché de consultas? El mecanismo de caché de Hibernate es extremadamente poderoso y flexible.
  • ¿Considera utilizar Hibernate Search? Dependiendo de su consulta, el índice Hibernate Search Full Text en la parte superior de Apache Lucene puede acelerar sus consultas (dado que su sistema de indexación es tan poderoso)
+0

No he realizado ningún ajuste de rendimiento en la configuración de base de datos. Había asumido que mi problema tenía más probabilidades de ser consultas mal concebidas o hacer la pregunta incorrecta muchas veces. Supongo que me gustaría encontrar una forma de reducir el número de consultas y sus gastos primero, y luego (después de reducir el uso en un 80%) acelerar el db mismo usando el almacenamiento en caché y otros trucos en esa carga reducida. Pero no soy un experto en ajustar el uso de DB. ¿Sugeriría ajustar el DB antes de la aplicación? – PanCrit

+0

Si está seguro de que el problema está en hibernación, ajustar la base de datos no ayudaría. Antes de sintonizar, use una herramienta de perfilador o algo que le ayude a rastrear exactamente la raíz de sus problemas de rendimiento, luego optimícela. Desafortunadamente, no hay una manera fácil. La buena noticia es que todos los IDEs en la actualidad tienen un soporte de perfiles decente. – razenha

0

¿Cuántos datos está almacenando en HSQLDB? No creo que funcione bien cuando se administran grandes conjuntos de datos, ya que solo se almacena todo en archivos ...

+0

No creo que sea tan grande en comparación con lo que hsqldb puede hacer. El archivo .script tiene casi 300K líneas de longitud (32891015 caracteres). Miré antes, y hay 3000 Mercados y 150K comercios almacenados en la base de datos. Podría ser 250,000 filas en total sobre todos los objetos. – PanCrit

0

Hubo una vez una herramienta llamada IronGrid/IronEye/IronTrackSql que hizo exactamente lo que estaba buscando. Lamentablemente, cerraron. Abrieron su producto de código abierto en el último minuto, pero no he podido encontrar el código fuente ni el binario desde hace bastante tiempo.

He estado usando YourKit para crear perfiles últimamente, en parte porque puede tener el perfil de tiempo de SQL para encontrar los enunciados más solicitados y las sentencias más antiguas. No es tan detallado como lo fue IronGrid, pero te proporciona información valiosa. En mi última sesión de ajuste de sesión de base de datos/hibernación, el problema resultó ser la hibernación y cómo y cuándo estaba haciendo una carga ansiosa o diferida, y agregando algunas modificaciones juiciosas de la predeterminada al seleccionar grandes cantidades de elementos.

0

Hay mucho que informar aquí. Tengo algunos resultados, y todavía estoy buscando buenas respuestas.

he encontrado un par de herramientas que ayudan a:

VisualVM (con BTrace, o el construido en Trace) pretende ayudar con la localización, pero no he podido encontrar ninguna herramienta que muestra el tiempo en llamadas de método.

YourKit tiene la reputación de ser útil; He pedido una licencia de código abierto.

Lo más útil que encontré es estadísticas integradas de Hibernate. Si configura hibernate.generate_statistics true en sus propiedades, puede enviar sessionFactory.getStatistics(), y ver estadísticas detalladas sobre qué objetos se han almacenado y recuperado, y qué afecta a las cachés. Encontré una de las respuestas que quería en qeuryStatistics, que informa de cada consulta compilada, la caché acierta y falla, la cantidad de veces que se ejecutó la consulta, cuántas filas se devolvieron y los tiempos de ejecución promedio, máximo y mínimo. Estos tiempos dejaban muy claro a dónde iba el tiempo.

Luego hice algunas lecturas sobre el almacenamiento en caché. La sugerencia de Razenha fue correcta. [Marcaré su respuesta como corresponde por ahora.] Agregué hibernate.cache.use_query_cache true a mis propiedades y agregué query.setCacheable(true); a la mayoría de mis consultas. También agregué <cache usage="read-write"/> a algunos de mis archivos .hbm.xml. Ahora la mayoría de mis estadísticas muestran un gran predominio de éxitos de caché, y el rendimiento es mucho mejor.

Todavía me gustaría algunas herramientas que me ayuden a rastrear el tiempo de ejecución para que pueda atacar los peores problemas en lugar de los más obvios, pero esto es de gran ayuda. Tal vez una de las herramientas de seguimiento anteriores resulte útil.

+0

yourkit es útil y fácil de usar. – PanCrit

0

En Terracotta 3.1, puede supervisar todas esas estadísticas en tiempo real utilizando la Consola de desarrollador de Terracotta. Puede ver gráficos históricos para estadísticas de caché y ver estadísticas de hibernación o estadísticas de caché en todo el clúster o por nodo.

Terracotta es de código abierto. Más detalles y descargar es en Terracotta for Hibernate.

Cuestiones relacionadas