Java  »  Articoli  »  JSP e servlet 

Qualche tempo fa ci siamo occupati di un problema molto importante ma spesso sottovalutato in fase di progettazione e realizzazione di una applicazione Web: le performance. Come ben sappiamo un servizio Web o una applicazione in genere deve avere un tempo di risposta adeguato alle esigenze dell'utente e la potenza di calcolo attuale ci da la possibilità di aspettarci dei tempi di esecuzione molto bassi per le elaborazioni più comuni.

Nel suddetto articolo ci siamo occupati della fase di test, anzi, di stress test, dove attraverso uno strumento molto utile, JMeter, abbiamo visto come martellare un server e valutare l'eventuale degradazione delle prestazioni. Quando ci accorgiamo di questo degrado, dunque, quali sono gli accorgimenti da mettere in atto?

Impareremo in questo articolo a dimensionare (in inglese, tuning) una applicazione java enterprise (JEE). I concetti che esporremo sono dei concetti generali; noi vedremo un caso concreto applicato all'application server JBoss 5. Del resto la gestione del tuning di un application server dipende fortemente dall'implementazione dello stesso.

Misurare le performance

Uno strumento utile a valutare le prestazioni è il già citato Jmeter, ma, qualsiasi altro strumento vogliate utilizzare per mettere sotto assedio la vostra applicazione andrà bene. Altri due strumenti sono fondamentali a tal proposito:

• JConsole, con il quale valutare in tempo reale le prestazioni della JVM (in particolare il consumo di memoria) su cui l'application server sta girando
• JMX dalla quale console potrete valutare uno ad uno gli elementi in gioco (connessioni, ejb, etc.) durante un'esecuzione. Quest'ultimo strumento in particolare si può consultare per JBoss accedendo all'interfaccia presente su http://localhost:8080/jmx-console (con l'installazione di default)

Tuning Datasource

Il collo di bottiglia di qualsiasi connessione è tipicamente legato alla gestione delle connessioni presso una base dati. Nel mondo "pre-enterprise" la gestione delle connessioni al database non era una cosa standard, quindi, utilizzando i driver JDBC, ci dovevamo preoccupare di creare una nuova connessione ad ogni uso, usarla e chiuderla. Un nuovo utilizzo avrebbe comportato una nuova creazione. Best practice è stata sempre infatti tenere un pool di connessioni ed allocarle alla bisogna.

Il data source di fatto rende standard questa best practice mettendo a disposizione dello sviluppatore una sorgente dati (un database, ma potrebbe essere qualsiasi sorgente) da interrogare. Compito dell'application server creare un pool di connessioni e gestirne il ciclo di vita. Quello che in fase di configurazione dovremo fare sarà dimensionare questo pool per non avere un eccessivo consumo di risorse (ogni oggetto nel pool consuma memoria) né tantomeno trovarsi nella situazione di creare troppe nuove connessioni, o, peggio ancora, di aspettare che una si liberi.

Altri articoli

Altre guide

Altre newsletter