Maurizio's blog 3.0

Girovagando tra la rete mi sono imbattuto in questo utilissimo tool utilizzabile on-line per la generazione della sezione <machineKey> del web.config, nel caso, molto concreto oggigiorno, si voglia implementare il meccanismo di SSO (Single Sign On) per le proprie applicazioni. In sostanza si tratta di effettuare il login una sola volta ed essere riconosciuto da n applicazioni che condividono in questo modo il contesto di sicurezza dell’utente, con indubbi benefici.

Tra le cause che provocano lo scaricamento immediato dell’AppDomain di una applicazione ASP .NET 2.0 è presente anche la cancellazione di una sub-directory della applicaizione principale, operata attraverso Windows Explorer. Infatti, dopo tale operazione nell’Event Viewer del server appare un messaggio di tipo informativo.

Questo comportamento è differente rispetto a ad ASP.NET 1.0/1.1, dove la stessa operazione non produceva assolutamente nulla nè l’engine veniva notificato dell’evento; quindi il contenuto della directory cancellata continuava ad essere considerato valido con il potenziale rischio di errore a run-time.

Il team di sviluppo di ASP .NET 2.0 ha considerato un bug il comportamento delle versioni precedenti (a mio avviso giustamente) ed ha modificato il comportamento come fosse un bug-fixing, cioè piuttosto di rischiare di servire una pagina non più esistente viene ora scaricato l’intero AppDomain. L’unica nota stonata è che nel messaggio scritto nell’ Event Viewer l’applicazione risulta scaricata a causa di “reason unknown” che non permette di capire immediatamente la causa, invece di un bel “reason:directory xyz deleted”

Dopo Kalen Delaney come già detto da Francesco, anche Itzik Ben-Gan ha aperto un suo blog. Chi ha letto i suoi articoli su T-SQL sa che Itzik è un personaggio davvero unico, come i suoi T-SQL Puzzle. Un’altro blog davvero imperdibile !

Riporto di seguito una lista, in ordine sparso, tratta dalla mia esperienza sul campo dei possibili accorgimenti e/o errori che influiscono sulla scalabilità o sulle performance e che tornano quindi utili quando si trasferisce su di un server di produzione una applicazione ASP .NET complessa con elevato numero di accessi concorrenti:

• Di default il numero di connessioni HTTP concorrenti su uno specifico indirizzo IP e per uno specifico AppDomain è pari a 2. Questo valore è sufficiente ad esempio nel caso di web services che vengono acceduti da un unica applicazione ASP .NET e le cui pagine non effettuano chiamate multiple allo stesso web service. Nell’ipotesi in cui il servizio web riceve richieste da più applicazioni o dalla stessa applicazione ma con chiamate multiple dalla stessa pagina, questo valore potrebbe causare che il worker thread che esegue la richiesta resti in attesa che si liberi una connessione, causando chiaramente una situazione di contesa delle risorse che porta a problemi di scalabilità e, nel peggiore dei casi. al riciclo dell’applicazione con esplicito messaggio di errore nel log degli eventi. Il numero delle connessioni può essere applicato per ogni singolo IP richiesto; il valore consigliato da Microsoft nel caso sopra esposto è di 12 * N ( dove N è il numero di CPU disponibili sul server)

• Gli assembly usati da più di una applicazione devono essere firmati con strong name e installati in GAC. In questo modo 1 sola copia dell’assembly è presente in memoria a prescindere dal numero di applicazioni che lo usano; se, al contrario, lo stesso assembly viene installato nella directory bin di ogni applicazione che lo utilizza, esso sarà presente in memoria N volte, una per applicazione, con conseguente spreco di risorse.
• Evitare situazioni che possono causare memory-leak. Ciò si verifica quando l’occupazione di memoria cresce in modo incontrollabile, ad es. perchè esistono oggetti i cui puntatori non possono essere gestiti nel modo corretto, tipico caso applicabile all’utilizzo di risorse unmanaged, e pertanto la memoria occupata da essi non può essere liberata dal GC ma solo da un riciclo dell’applicazione o peggio ancora da un riavvio di IIS. Le risorse unmanaged devono essere liberate implementando un distruttore per l’oggetto che ne fa uso oppure esplicitamente da codice attraverso l’interfaccia IDisposable. Tra le condizioni che possono provocare un alto utilizzo della memoria e quindi il rischio di memory leak meritano una menzione particolare l’utilizzo di oggetti del Framework che creano dinamicamente assembly. Ad esempio, se ogni volta che si intende serializzare un oggetto in XML si crea una istanza della classe xmlSerializer utilizzando una particolare versione di overload del suo costruttore, e cioè quella che prevede il passaggio degli extraTypes, per ogni istanza sarà creato un assembly dinamico dietro le quinte. L’assembly dinamico non potrà essere scaricato dalla memoria se non quando viene scaricato l’Application Domain che lo contiene. Altre situazioni analoghe a quest’ultima riguardano l’uso di RegEx o di xmlTransform. In quest’ultimo caso il problema è identico in quanto durante una trasformazione XSLT se si utilizzano blocchi di script inline il .NET Framework genera un assembly dinamico che resta in memoria fino al riciclo del processo host.  Maggiori informazioni qui e qui.
• Il riciclo di un application pool avviene di default ogni 1740 minuti, pari a 29 ore. Questo valore non è chiaramente appropriato per tutti gli scenari. Sarebbe a mio avviso preferibile impostare il riciclo ad un’ora prefissata, magari notturna.
• Quando un application pool viene riciclato per un qualsiasi motivo non sempre viene tracciato nel log degli eventi. Per permettere il log degli eventi al verificarsi di determinati eventi occorre modificare il metabase di IIS, impostando la proprietà LogEventOnRecycle con il parametro desiderato. A seconda della politica di riciclo impostata sul server di produzione è preferibile settare questo parametro al valore più opportuno per un troubleshooting più efficiente. Maggiori informazioni in questo articolo.
• Il riciclo di un processo ASP .NET può avvenire anche al raggiungimento di una certa soglia di memoria occupata dallo stesso (parametro memoryLimit in machine.config o nelle proprietà dell’applicazione web in IIS6). Questa soglia è impostata di default al 70% di memoria fisica disponibile nel sistema, e andrebbe tarata su misura in base alle proprie esigenze. Da notare che il calcolo percentuale della memoria a disposizione viene influenzato dal parametro webGarden e cpuMask. Quindi, se si imposta il parametro webGarden a true e cpuMask a 4 CPU, la soglia di memoria RAM oltre la quale si scatena il riciclo del processo è 1/4 della percentuale impostata nel parametro memoryLimit, quindi una soglia decisamente bassa che potrebbe far aumentare il numero di ricicli che si verificano.
• Il valore dell’attributo “debug” dell’elemento “compilation” nel file di configurazione “web.config” deve essere impostato a “false” in ambiente di produzione. Per una trattazione dei problemi a cui si può andare incontro lasciando il valore predefinito “true” è possibile far riferimento ad un mio precedente post sull’argomento.

Chiaramente questa non vuole essere una lista esaustiva circa tutti i possibili scenari a cui si può andare incontro quando si effettua il deployment in produzione di una applicazione web, ma solo una semplice check-list pronta all’uso che provvederò magari ad aggiornare man mano che entrano in gioco altri fattori.

L’utilizzo della cache in applicazioni web non è sempre intuitivo come potrebbe sembrare. Se inseriamo un oggetto in cache assegnandogli, ad es., una scadenza assoluta di 1 ora, potremmo pensare che lo stesso rimanga in cache fino a che non scade. Invece non è così. Un oggetto in cache può in qualsiasi momento antecedente la sua scadenza (cioè quando è ancora valido) essere eletto per una operazione di garbage collection; quindi può essere distrutto e, in tal caso, la memoria da esso occupata viene liberata, a prescindere se il suo periodo di validità si è esaurito oppure no. Questo comportamento potrebbe verificarsi nei casi in cui il sistema richieda memoria per compiere una qualche operazione e nello stesso tempo la memoria cache risulta occupata. Morale: non bisogna mai dare per scontato che un oggetto inserito in cache sia disponibile anche se la sua scadenza è molto ampia. Questo meccanismo può essere disabilitato impostando l’enumerazione CacheItemPriority a CacheItemPriority.NotRemovable. In questo caso un oggetto in cache entrerà a far parte di un garbage collector solo se è scaduto, altrimenti sarà sempre valido. Questa impostazione torna utile nei casi in cui non è possibile ricreare l’oggetto dopo averlo messo in cache; infatti essa viene utilizzata dalla sessione InProcess di ASP .NET.

Un altro aspetto da considerare è che la cache è specifica di un certo Application Domain, e non cross appdomain. Questo significa che è globale a livello della applicazione che ne fa uso, e quindi 2 applicazioni (ovvero 2 appdomain) utilizzano sempre cache diverse e quindi non condivise. Ma come fare allora se vogliamo condividere la cache in più di una applicazione, in modo, ad es., che se inserisco un oggetto in cache dalla applicazione A anche l’applicazione B possa vederlo ? In uno scenario complesso e, soprattutto, in una web farm, è possibile memorizzare gli oggetti in un repository differente dalla memoria cache, ad. es. in un database. Questo approccio garantisce chiaramente una altissima disponibilità del servizio di caching, anche in caso di riavvio del sistema. Un approccio più semplice consiste nel creare un web service (quindi un’altra web application) che espone metodi get/set per gli oggetti da inserire in cache usando il meccanismo nativo di ASP .NET. In questo modo qualsiasi applicazione che usa il web service potrà utilizzare la cache, che sarà condivisa perchè l’application domain è sempre lo stesso.

Oramai le attenzioni degli sviluppatori sono concentrate sull’accoppiata Windows Vista e .NET Framework 3.0, con tutte le tecnologie annesse che non sto ad elencare. Approfitto di questo post dell’amico Mighell del nuovo user group del sud Italia dotNetSide  (a proposito, complimenti per l’iniziativa e per quanto fatto sinora !), per mettere nel mio blog il riferimento necessario ai vari link per il download del .NET Framework 3.0 RC1. Buon download a tutti !

Questa è una domanda che mi sono posto anch’io parecchie volte: il controllo dei limiti inferiore e superiore di un array che il compilatore JIT opera durante l’esecuzione di una tipica applicazione .NET è una operazione onerosa o no, e se si di quanto ? Ci si può fare una idea abbastanza significativa leggendo questo post di Rico Mariani, il quale ha effettuato dei test comparati su una applicazione .NET che utilizza il compilatore JIT tradizionale e la stessa applicazione che invece utilizza un compilatore JIT da lui stesso modificato, e precisamente senza il controllo dei limiti degli array (mscorjit.dll). Dal post si evince che il controllo sui limiti di un array non introduce un overhead significativo, anche se ritengo che la valutazione dipende dal tipo di applicazione. Comunque, aggiungo, se si programma in C# è possibile costruirsi routine di codice unsafe che permettono, tra le altre cose, di gestire array ad alte prestazioni memorizzate sullo stack e non sull’heap gestito, i cui membri sono acceduti sfruttando la semplice aritmetica dei puntatori,  senza alcun controllo di nessun tipo. Questo argomento è stato da me già trattato (spero esaurientemente :)) in un articolo pubblicato sul sito xplayn.org.

Di questo link ne faccio un post nel mio blog per tenerlo sempre a portata di….mouse!. Trattasi di una raccolta di link di Scott Gu, uno dei maggiori esperti mondiali di ASP .NET e di .NET in generale, riguardanti tips & tricks, approfondimenti e veri e propri tutorial per chi sviluppa applicazioni web di livello enterprise. Il livello di dettaglio e la chiarezza espositiva di Scott Gu è davvero superlativa, e attraverso il suo blog si entra in possesso di “conoscenza” che forse nemmeno i libri di livello avanzato o i workshop tecnici più spinti riescono a fornire. Ho avuto la fortuna di assistere ad un evento tecnico tenutosi a Roma un paio di anni fa, in cui Scott parlò del suo argomento preferito, ovvero ASP.NET, e posso affermare con assoluta certezza che Scott Gu è davvero un grande e che le sue conferenze meritano sempre di essere ascoltate con attenzione.

Il nuovo modello di compilazione-deployment di ASP .NET 2.0 non è certamente facile da usare e nemmeno intuitivo, soprattutto per chi proviene da ASP .NET 1.0/1.1. 

Non a caso Microsoft ha rilasciato un add-in, il Web deployment Project, praticamente in concomitanza con l’uscita di Visual Studio 2005, che permette di utilizzare il modello di compilazione di ASP.NET 2.0, pur garantendo un alto grado di flessibilità; infatti è possibile compilare una applicazione web  in un singolo assembly, oppure in un assembly separato per ogni sua directory, oppure ancora in un assembly separato per ogni pagina/controllo.

In aggiunta, poco tempo dopo è stato rilasciato un’altro add-in, il Web Application Project, di cui magari parlerò in in post a parte. Per il momento mi limito a dire che ambedue questi add-in non sono supportati da Visual Studio in versione Visual Web Developer.

Se si prova ad lanciare in esecuzione una applicazione ASP .NET 2.0, ogni pagina è compilata “al volo” su richiesta (comportamento di default), e per ogni pagina richiesta viene generato un singolo assembly a cui viene attribuito un nome “non user-friendly”. Questo provoca pochissimi vantaggi, anzi, a mio avviso uno solo, e gravi svantaggi. A questa conclusione ci sono arrivato dopo parecchi mesi di utilizzo di Visual Studio 2005, praticamente dalle versioni beta, a dispetto di un iniziale entusiasmo per il nuovo modello di compilazione. Infatti, in apparenza basta far puntare VS ad una directory del file system che contiene una web application e lanciarla in esecuzione per vederla nel browser senza una sua preventiva compilazione. Non solo, è anche possibile modificare il sorgente della pagina mentre la stessa è in esecuzione, salvare la pagina per vedersi applicate immediatamente le modifiche al codice sorgente senza una ricompilazione (questo piccolo apparente “miracolo” è dovuto al fatto che ogni pagina è compilata in un assembly separato, quindi è possibile scaricare dalla memoria il singolo assembly e ricaricarlo ad ogni modifica della pagina; questo è l’unico vantaggio di cui parlavo prima) . A prima vista tutto ciò può sembrare favoloso, in realtà questo comportamento nasconde parecchie insidie. Prima di tutto affinchè questo modello funzioni è necessario copiare sulla macchina di deployment anche i sorgenti della propria applicazione, praticamente occorre replicare il contenuto dell’applicazione presente sulla propria macchina di sviluppo. Questa è, a mio avviso,una condizione inaccettabile su applicazioni pubbliche che manipolano dati sensibili o che effettuano transazioni economiche; forse è appena appena accettabile su applicazioni funzionanti in intranet che non trattano dati personali.

Inoltre, il nome dell’assemby contenente la pagina compilata è generato a run-time ed univoco, anche se viene ricompilata la stessa pagina compilata precedentemente. Questo significa che è impossibile per una pagina X mantenere un riferimento alla pagina Y, perchè la classe di quest’ultima ed il suo assembly saranno “nominati” solo a run-time con un nome non prevedibile. Questo è davvero un grande problema per coloro che usano web control caricati dinamicamente a run-time, perchè significa che non è possibile ottenere un riferimento “strongly typed” ad un web control caricato dinamicamente, ma solo un riferimento generico “UserControl”, a meno di non utilizzare il tag @Register sulla pagina (il quale forza l’assembly della pagina che contiene il tag a mantenere un riferimento all’assembly che contiene lo user control), oppure, se l’applicazione è compilata in assembly separati per ogni sua directory, occorre che la pagina che referenzia lo user control e quest’ultimo risiedano nello stesso assembly, quindi nella stessa directory fisica.

L’add-in Web Deployment Project permette di “precompilare” l’intero sito in uno o più assembly, e di assegnare a quest’ultimi nomi statici, quindi ripetibili, che permettono alla classe che contiene il codice per una data pagina di essere referenziata senza problemi da un assembly/classe esterna in quanto il suo nome non cambia ad ogni ricompilazione. Utilizzo questo add-in praticamente da sempre e sinceramente, ma è solo un parere personale su cui mi piacerebbe ascoltare esperienze di altri sviluppatori, non riesco ad immaginare una web application che non ne faccia uso, chiaramente intendo applicazioni line of business ad alta disponibilità che girano su server pubblici con un alto indice di richieste.

E’ disponibile per il download la prima CTP (Agosto 2006) di ADO .NET vNext, comprendente l’entity framework che supporta l’Object Relational Mapping, ovvero l’entity data model per effettuare query sulle entità stile sql (LINQ)

In questi giorni di vacanze forzate a casa per via di qualche ‘problemuccio’ di salute (per fortuna é passato tutto :)) ho riassaporato 2 tra le mie passioni più grandi: la musica e la lettura. Ho letto altri libri nel frattempo usciti della saga di Carlos Castaneda, scrittore e antropologo peruviano scomparso da qualche anno, e delle sue esperienze con don Juan, un indios Yaqui del Messico. Si tratta di una delle storie più affascinanti che abbia mai letto circa culture e filosofie completamente diverse dalla nostra, che mettono in risalto quanto i nostri sogni, le nostre ansie, paure, il ns. egocentrismo siano nulla di fronte all’immensità che ci circonda. E’ una lunghissima storia che tenta di dare un significato a ciò che la scienza, la ns. cultura, religione cataloga da sempre come ‘inspiegabile’. Il blues è l’altra mia passione, parlo di quella musica nata nei pressi del delta del Mississipi river per opera di gente di colore, molto povera, che lavorava nelle piantagioni della zona, e che attraverso la musica blues esprimeva le ansie, il disagio, le sofferenze di una vita fatta di stenti, ma anche le proprie gioie fugaci, i sentimenti, i sogni, la speranza che un giorno le loro condizioni di vita potessero essere migliori. Tra gli esponenti di spicco del blues di quella zona d’America e tra i miei bluesman preferiti in assoluto menziono Muddy Waters e John Lee Hooker, due artisti il cui connubio voce-chitarra elettrica è di quelli che fanno venire la pelle d’oca a chi li ascolta.

P.S. Scrivo questo post mentre sono in ferie, quindi senza PC (volutamente) e naturalmente senza connessione a lnternet. Ma già mi mancano i blogs, quindi sto usando le note del mio cellulare per poi sincronizzare!! 🙂

So, damn right i’ve got the blues, from my head down to my shoes (B.G.)

La versione di NDOC per il Framework 2.0 sembra che non vedrà mai la luce, almeno leggendo le ultimissime notizie. Peccato, ho usato NDOC su parecchi progetti e devo dire che sono sempre stato soddisfatto dei risultati raggiunti con l’utilizzo di questo tool, soprattutto quando manca il tempo per documentare un progetto usando classiche soluzioni alternative. Però potremo produrre docuntazione “MSDN like” usando Sandcastle, il tool usato internamente da Microsoft per la documentazione tecnica dei progetti che la stessa ha deciso di rendere disponibile al download. Si tratta di un tool che via reflection ottiene le informazioni sui vari assembly integrandole con la eventuale documentazione inserita direttamente nel codice sorgente, producendo un contenuto che, manipolato via XSL, permette di ottenere la classica documentazione style MSDN che siamo abituati a vedere ogni giorno.