Sintonia JSF

Question

Incontrare un problema in cui JSF sta riempiendo le nostre sessioni. L'altro giorno abbiamo avuto un crash del sistema. Ho inviato l'heap a IBM per la revisione e abbiamo scoperto che avevamo sessioni di 50 m. Hanno trovato componenti JSF nella sessione e alcuni molto grandi.

Quindi, c'è qualche sintonia che può essere fatta? Elementi di configurazione da guardare? O altra direzione.

Il nostro sistema è costruito usando JSF e Spring per il livello di presentazione, il back-end è EJB, Spring e Hibernate tutti in esecuzione su WebSphere 6.1.

Answer 1

JSF è una tecnologia utile, ma puoi sicuramente impiccartici.

Sembra che tu stia gonfiando le dimensioni dello stato di visualizzazione (impostando valori elevati sui componenti) o stai perdendo riferimenti ai componenti in altri stati di sessione (il che sarebbe negativo). Un altro potenziale colpevole sarebbe una visione eccessivamente ampia (ho visto la facilità con cui le persone possono costruire alberi dell'interfaccia utente portano a grafici di controllo molto grandi con tabelle di dati ovunque). So che IBM offre controlli di testo completo e fogli di calcolo: non posso commentare l'effetto che questi avranno sull'impostazione dello stato.

Il frutto in sospeso è quello di controllare i bean gestiti configurati per l'ambito della sessione in faces-config.xml .

JSF salva due cose tra le richieste:

• la vista (tutti i controlli sulla pagina)
• lo stato di visualizzazione (lo stato dei controlli)

Questi sono separati perché alcuni controlli, come i figli di una tabella di dati, possono avere più stati (uno per ogni riga). Lo stato può essere salvato in un campo nascosto nel modulo (che, se non crittografato, può rappresentare un grosso rischio per la sicurezza) o nella sessione. Al fine di ospitare più finestre del browser che condividono la stessa sessione (e, in alcune implementazioni, supporto per il pulsante Indietro), vengono memorizzate più viste.

• Dovrebbe esserci un'opzione di configurazione per impostare il numero di stati di visualizzazione che l'app manterrà nella sessione per un determinato utente in qualsiasi momento.
• È possibile misurare la dimensione dello stato di visualizzazione fornendo un StateManager che misura la dimensione della vista / stato salvati (configura un StateManager in faces-config.xml con un costruttore pubblico che accetta un StateManager - vedi specifiche JSF PDF per maggiori dettagli; lo stato è serializzabile e puoi verificarne le dimensioni scaricandolo su uno stream) .

La maggior parte delle app JSF create da IDE hanno bean di backup. Sarebbe possibile, tramite l'ambito del bean di sessione, mantenere lo stato più a lungo del previsto, mettendo a dura prova la sessione. Poiché tende a esserci un bean di supporto per pagina, più pagine hai, più grande sarà il problema. Controlla faces-config.xml per vedere se questa è una potenziale fonte di problemi.

Qualcos'altro che potresti fare sarebbe configurare un HttpSessionAttributeListener nel tuo web.xml . Puoi ottenere una stack trace per identificare le aree problematiche nella tua app.

Answer 2

Questo è il secondo sistema di cui ho sentito parlare che è morto a causa di JSF e della creazione eccessiva di oggetti. L'altro usava anche Spring e Hibernate nel back-end. Creazione del profilo con Optimize Ha mostrato che la risposta del backend era dell'ordine dei millisecondi per tutte le richieste, ma è possibile cronometrare il rendering del browser con il cronometro perché ci sono voluti così tanto - 30 secondi fino a diversi minuti. La memoria consumata dal client era ridicola.

Ero solo un osservatore, non un membro di quel team di progetto. Dovrò chiedere se il problema è mai stato risolto e, in tal caso, quale potrebbe essere stata la soluzione.

Ma se due punti fanno tendenza, direi che JSF potrebbe essere fatalmente imperfetto. Personalmente, ne sto completamente alla larga.

Perché non provare un front-end Web di Spring e vedere se questo aiuta? Se segui il linguaggio Spring, dovrebbe essere una questione relativamente semplice di sostituire JSF con JSP e controller Spring basati su JSTL.

Answer 3

Stavo lavorando a un progetto JSF e ho scoperto che c'era un bug in cui stavamo aggiungendo più elementi JSF h: form. Il risultato è una copia dell'intero viewstate inclusa in ogni modulo. Riducendo fino a 1 modulo per pagina, le pagine sono state ridotte da ~ 2M a ~ 300K.

Answer 4

Potresti riscontrare problemi con molti bean di backup come ambito della sessione.

Puoi provare a guardare MyFaces Orchestra . Questa è una libreria che fornisce un ambito di conversazione, quindi una volta che un utente ha terminato con un particolare set di bean verrà rimosso dalla sessione.

Comprendo che Spring WebFlow ha caratteristiche simili ma non ci ho mai pensato!

Answer 5

JSF memorizza le viste in sessione per supportare la sua ricca architettura basata su componenti (è necessario mantenere lo stato di visualizzazione) e può riempire l'heap se non utilizzato correttamente. Se non hai grandi flussi di lavoro, scegli sempre un numero ridotto di visualizzazioni per sessione. Evita anche di mantenere il backingbeans il più possibile. Utilizzare il tag personalizzato per rendere l'oggetto dati solo per il ciclo di richiesta successivo. Possiamo anche usare Spring Web Flow con JSF, che introduce l'ambito della vista e l'ambito del flusso se abbiamo lunghi flussi di lavoro nell'applicazione per ridurre il numero di visualizzazioni configurate nella sessione. JSF può essere utilizzato per rendere facilmente ricca l'interfaccia utente, il che aiuta a creare un'applicazione Web simile all'applicazione desktop. Assegnare un heap specifico al framework JSF per fare il suo lavoro. Ma usa la memoria in modo efficiente sul lato dell'applicazione e assicurati che non ci siano perdite di memoria. Tutte le perdite di memoria devono essere investigate e corrette durante lo sviluppo stesso. Utilizzare sempre un profiler per trovare perdite di memoria e colli di bottiglia delle prestazioni esistenti nell'applicazione.

Mat.

Answer 6

Se si utilizza MyFaces < 1.1.6 c'è un'enorme perdita di memoria nel modo in cui memorizza nella cache le vecchie viste serializzate in modo efficace, senza mai lasciarle rilasciare in modo che possano essere raccolte. Ho avuto un grave problema e anche sessioni da 50 Mb. Un rapido aggiornamento di MyFaces ha risolto il problema senza problemi.

Answer 7

Configura la persistenza della sessione nel database e utilizzerà l'algoritmo meno utilizzato per eliminare le sessioni meno utilizzate dalla memoria. Ha alte prestazioni (se configurato correttamente) e ti aiuterà concretamente e velocemente.

Answer 8

Un po 'di un vecchio argomento, ma recentemente mi sono imbattuto in questo. Spesso, Visualizza e Visualizza stato vengono memorizzati (come precedentemente menzionato) e riempie la sessione per consentire al pulsante Indietro di funzionare. Esistono parametri per ordinare questo nei descrittori di distribuzione (web.xml) che devono essere impostati.

Più istanze di determinate librerie potrebbero richiedere più di un'impostazione di parametro, ad esempio quando si utilizzano MyFaces e JSF RI. Per impostazione predefinita, possono essere impostati su valori piuttosto alti (20 e 16 credo, rispettivamente). Ciò significa che puoi utilizzare 20 volte lo spazio che dovresti avere per (parti di?) La sessione.

Answer 9

Suggerimenti per l'ottimizzazione JSF per l'ambiente di produzione:
 - L'utilizzo di immagini, risorse CSS e JavaScript deve essere eseguito con tag HTML standard (img,link,script) non lato server e assicurarsi di impostare #{request.contextPath} prima dell'URL per evitare problemi relativi ai percorsi.
 - Memorizza le sezioni statiche della pagina (menu,header,footer) usando omnifaces cache
 - Impostare refresh-period variabile su -1
 - imposta project-stage su Produzione
 - Esamina i filtri del codice, se presenti

Inoltre, controlla il mio articolo " Java Server Volti nelle applicazioni della vita reale & Quot; su DZone, ti fornirà un quadro completo di JSF negli ambienti di sviluppo, test e produzione.