2009-04-24 16 views
5

Possiedo un'applicazione Java open source che utilizza Hibernate e HSQLDB per la persistenza. In tutti i miei test sui giocattoli, le cose corrono veloci e tutto va bene. Ho un cliente che esegue il software da diversi mesi continuamente e il loro database è cresciuto significativamente nel tempo e le prestazioni sono diminuite gradualmente. Alla fine mi è venuto in mente che il database potrebbe essere il problema. Per quanto posso dire dalle istruzioni di registro, tutto il calcolo nel server avviene rapidamente, quindi questo è coerente con l'ipotesi che il DB potrebbe essere in errore.Come ottimizzare le prestazioni dell'app hsqldb/hibernate

So come eseguire il normale profilo di un programma per capire dove sono gli hot spot e che cosa richiede molto tempo. Ma tutti i profiler che conosco monitorano i tempi di esecuzione all'interno del programma e non ti danno alcun aiuto sulle chiamate a risorse esterne. Quali strumenti usano le persone per profilare i programmi che utilizzano chiamate db esterne per scoprire dove ottimizzare le prestazioni?

Un piccolo cieco che cerca in giro ha già trovato alcuni punti caldi: ho notato una chiamata dove stavo enumerando tutti gli oggetti di una particolare classe per scoprire se ce ne fossero. Una modifica di una riga al criterio [.setMaxResults (1)] ha cambiato quella chiamata da mezzo secondo a praticamente istantanea. Vedo anche luoghi in cui faccio la stessa domanda dal db molte volte all'interno di una singola transazione. Non ho ancora capito come memorizzare la risposta, ma quello che voglio veramente è uno strumento che mi aiuti a cercare questo tipo di cose in modo più sistematico.

risposta

3

Purtroppo, per quanto ne so, non esiste uno strumento per questo.

Ma ci sono alcune cose che si potrebbe desiderare di check:

  • Stai usando eager loading, invece di caricamento pigro? Dalla descrizione del tuo problema, sembra davvero che tu non stia utilizzando il caricamento lazy ...
  • Hai acceso e configurato correttamente il tuo caching di secondo livello? Compresa la cache di query? Il meccanismo di memorizzazione nella cache di Hibernate è estremamente potente e flessibile.
  • Hai in mente di utilizzare Hibernate Search? A seconda della query, l'indice Hibernate Search Full Text su Apache Lucene può velocizzare le tue query (dal momento che il sistema di indicizzazione è così potente)
+0

Non ho eseguito alcuna ottimizzazione delle prestazioni nella configurazione del DB. Avevo pensato che il mio problema fosse più probabile che si trattasse di domande mal concepite o di porre la domanda sbagliata troppe volte. Credo che mi piacerebbe trovare un modo per ridurre il numero di query e le loro spese prima, e poi (dopo aver ridotto l'utilizzo dell'80%) accelerare il db stesso usando la cache e altri trucchi su quel carico ridotto. Ma non sono un esperto nell'ottimizzazione dell'uso del DB. Suggeriresti di sintonizzare il DB prima dell'applicazione? – PanCrit

+0

Se si è certi che il problema sia in ibernazione, l'ottimizzazione del DB non sarebbe di aiuto. Prima della messa a punto, utilizzare uno strumento profiler o qualcosa che aiuti a tracciare esattamente la radice dei problemi di prestazioni, quindi ottimizzarlo. Sfortunatamente, non esiste un modo semplice. La buona notizia è che tutti gli IDE oggi hanno un supporto di profilazione decente. – razenha

0

Quanti dati stai archiviando in HSQLDB? Non penso che funzioni bene quando si gestiscono grandi quantità di dati, dato che memorizza tutto nei file ...

+0

Non penso sia enorme rispetto a quanto può fare hsqldb. Il file .script ha una lunghezza di quasi 300 K (32891015 caratteri). Ho guardato prima, e ci sono 3000 mercati e transazioni 150K memorizzati nel DB. Potrebbe essere un totale di 250K di righe su tutti gli oggetti. – PanCrit

0

C'era una volta uno strumento chiamato IronGrid/IronEye/IronTrackSql che faceva esattamente quello che cercavi. Sfortunatamente, fallirono. Hanno fatto open source il loro prodotto all'ultimo minuto, ma non sono stato in grado di trovare una fonte o un file binario per un po 'di tempo.

Sto usando YourKit per il profiling ultimamente, in parte perché puoi avere il tempo SQL del profilo per trovare le istruzioni più chiamate e le istruzioni più lunghe in esecuzione. Non è dettagliato come IronGrid, ma ti dà informazioni preziose. Nella mia ultima sessione di sintonizzazione database/ibernazione, il problema si è verificato in ibernazione e come e quando si stava eseguendo il caricamento ansioso o pigro e aggiungendo alcune discrezionali sostituzioni del valore predefinito quando si seleziona un numero elevato di elementi.

0

Molto da segnalare qui. Ho dei risultati e sto ancora cercando buone risposte.

ho trovato un paio di strumenti che aiutano:

VisualVM (con BTrace, o il costruito nel Trace) pretende di aiutare con l'analisi, ma non sono stati in grado di trovare qualsiasi strumento che mostra i tempi sulle chiamate al metodo.

YourKit è noto per essere utile; Ho chiesto una licenza open source.

La cosa più utile che ho trovato è la statistica incorporata di Hibernate. Se si imposta hibernate.generate_statistics true nelle proprietà, è possibile inviare sessionFactory.getStatistics() e visualizzare statistiche dettagliate su quali oggetti sono stati memorizzati e recuperati e quali sono gli effetti sulle cache. Ho trovato una delle risposte che volevo nel qeuryStatistics, che riporta per ogni query compilata, i colpi e le mancanze della cache, il numero di volte in cui la query è stata eseguita, il numero di righe restituite e i tempi di esecuzione medi, minimi e minimi. Questi tempi hanno reso abbondantemente chiaro dove andava il tempo.

Ho quindi fatto qualche lettura sul caching. Il suggerimento di Razenha era giusto. [Segnerò la sua risposta per ora.] Ho aggiunto hibernate.cache.use_query_cache true alle mie proprietà e ho aggiunto query.setCacheable(true); alla maggior parte delle mie domande. Ho anche aggiunto <cache usage="read-write"/> ad alcuni dei miei file .hbm.xml. Ora la maggior parte delle mie statistiche mostra una vasta predominanza di hit della cache e le prestazioni sono decisamente migliori.

Vorrei ancora alcuni strumenti per aiutarmi a tracciare i tempi di esecuzione in modo da poter attaccare i problemi peggiori piuttosto che il più ovvio, ma questo è di grande aiuto. Forse uno degli strumenti di tracciatura di cui sopra si rivelerà utile.

+0

yourkit è utile e facile da usare. – PanCrit

0

In Terracotta 3.1, è possibile monitorare tutte queste statistiche in tempo reale utilizzando la Console per gli sviluppatori di Terracotta. È possibile visualizzare grafici storici per le statistiche della cache e visualizzare le statistiche di ibernazione o le statistiche della cache a livello di cluster o su base per nodo.

La terracotta è open source. Maggiori dettagli e download sono allo Terracotta for Hibernate.

Problemi correlati