XML XSLT e JScript possono generare memory leak in web application .NET
Può un’applicazione Web passare da 30 utenti simultanei a 100 semplicemente con un utilizzo attento delle tre tecnologie che oggi costituiscono il cuore dello sviluppo?
L’esperienza mi porta a dire di si confermandomi quanto già appreso in un precedente episodio sempre con queste 3 tecnologie.
Il sintomo, visibile col semplice Task Manager, è quello di un costante aumento della memoria del W3WP associato al vostro sito web su IIS6.
Altro segno tangibile che state incorrendo nel problema di compilazioni continue e quindi in una eccessiva frammentazione della memoria di .NET è la presenza in %TEMP% di DLL dal nome temporaneo.
La prova è la presenza nel vostro codice XSL di JScript in maniera simile e quando riportato qui sotto:
1: /* Inclusione di JScript */
2: <xsl:include href="utility.xsl"/>
3:
4: /* Richiamo della funzione JScript*/
5: <xsl:value-of select="sole24csharp:DataITA(@Data)"/>
6:
7:
L’effetto di tale pratica è che il motore di .NET esegue continue compilazioni ed alloca memoria per la corrispondende DLL fino a quando tutto l’AppDomain non viene distrutto.
Quest’ultimo evento in IIS6 coincide con il processo HOST w3wp.exe e dunque il clean-up della memoria avviene solo per recycle del processo.
Eliminando il codice JScript, che provoca l’invocazione ad ogni trasformazione del motore di compilazione di Jscript, il problema non si presenta e l’applicazione scala perfettamente
1: /* Compilazione */
2: <xsl:value-of select="sole24csharp:DataITA(@Data)"/>
3:
4: /*statico*/
5: <xsl:value-of select="@Data"/>
6:
7:
Questo aspetto è particolarmente delicato quando l’applicazione effettua del caching e quindi può accadere, come nel nostro caso, che il compilatore viene invocato, la DLL generata, ma non viene mai usato perché non si entra mai in quel code path.
Analizzando i dati di allocazione del GC vedrete che tutto funziona perfettamente ma il processo continua a mangiare memoria fino a l recycle e che il vostro disco avrà migliaia di DLL nella directory temporanea.
Una piccola accortezza che cambia drammaticamente la scalabilità di una applicazione web e consente il consolidamento di più applicazioni nella stessa farm.


(4.5 out of 5)