Nel file di configurazione web.xml è possibile definire molti parametri per modificare il comportamento di una applicazione web. In questo post vedremo nel dettaglio i parametri che permettono di configurare il modo in cui sono trasferiti i dati dal server al browser nel caso di una applicazione web che utilizza RichFaces 3.3.3 (molti dei parametri sono disponibili anche nella versione 4 di RichFaces).

Una possibile configurazione porta a questa situazione (il monitoraggio è stato effettuato con firebug e ):

I due grafici a torta mostrano la ripartizione del traffico di rete necessario per caricare una pagina web; il grafico a sinistra è relativo al primo caricamento di una pagina (quindi nel caso di la cache del browser vuota), quello a destra è relativo ai caricamenti successivi. La cache del browser è molto importante per le applicazioni web intranet in cui gli utenti sono sempre gli stessi e quindi il caso di cache piena è molto probabile.

Il parametro org.richfaces.LoadScriptStrategy serve per decidere se trasferire sul browser un unico file con tutto il codice JavaScript di RichFaces o più file solo con la parte che serve effettivamente nella pagina. Il parametro org.richfaces.LoadStyleStrategy è l’equivalente per i css. Dopo aver messo ALL c’è un aumento della dimensione totale della pagina, ma una diminuzione delle richieste effettuate:

L’utilizzo di questi due parametri dipende dal tipo di applicazione scaricata: se si utilizzano pochi componenti RichFaces e vogliamo che anche il primo caricamento della pagina sia veloce è meglio non utilizzare questo parametro. Considerando il fatto che un framework come RichFaces viene utilizzato prevalentemente per applicazioni Desktop Replacement questi due parametri sono molto utili e da utilizzare sempre.

Il parametro enable-cache serve per abilitare/disabilitare la cache del browser, la descrizione nella documentazione è:

Enable caching of framework-generated resources (javaScript, CSS, images, etc.). For debug purposes development custom javaScript or Style prevents to use old cached data in a browser

Mettendolo a true si sfrutta la cache del browser per i file JavaScript e i css di RichFaces. Negli url di queste richieste c’è la versione di RichFaces quindi non ci sono problemi di cache quando c’è un aggiornamento del framework. Usando questo parametro si riduce drasticamente il traffico quando ci sono i dati in cache:

La compressione del traffico è ormai supportata da tutti i browser e può essere effettuata dall’application server, da un web server messo davanti all’application server o da codice all’interno della web app. La libreria ehcache ha anche un filtro che esegue la compressione gzip del traffico. Per comprimere i dati i due jar di ehcache devono essere aggiunti nel classpath, la configurazione da aggiungere nel web.xml è invece la seguente:

    gzipFilter
    net.sf.ehcache.constructs.web.filter.GzipFilter


    gzipFilter
    /*

Il risultato finale è questo (siamo passati da circa 500k di download a ogni richiesta a meno di 12k nel caso di cache piena!):

Un altro parametro disponibile nel web.xml che influisce molto sul traffico di rete in una web application con jsf è javax.faces.STATE_SAVING_METHOD. Questo parametro indica dove salvare lo stato dei componenti jsf (o view state), può assumere due valori:

• server: i dati sono salvati nella sessione utente
• client: i dati sono salvati in un campo hidden in ogni pagina

La teoria ci dice che scegliendo di salvare i dati sul server si ha meno occupazione di banda ma più occupazione di memoria. Scegliendo di salvarli sul client si possono gestire più utenti a parità di hardware in quanto la sessione utente è più piccola ma si ha più traffico di rete. Questa è la teoria, ma in pratica quanto è il traffico di rete aggiuntivo salvando lo stati dei componenti sul client? Per pagine non banali è molto alto e viene percepito un rallentamento anche dall’utente. Da notare che usando RichFaces questo traffico aggiuntivo c’è ad ogni chiamata al server, anche in tutte le chiamate ajax. Per questo motivo il consiglio è quello di usare il salvataggio sul client solo nel caso in cui nella vostra web app ci siano pochi componenti RichFaces in ogni pagina.