Argomento molto interessante, mi occupo di web-application da molto tempo e questo problema è sempre ricorrente. L’aumentare del numero di utenti che visitano un sito web è direttamente proporzionale all’attenzione che si deve porre nei confronti dei vari meccanismi che si occupano di far interagire ui e database. Per rendere questo “collegamento” performante si può utilizzare il Connection Pooling.
Il connection pooling è una cache delle connessioni mantenute dal database, queste rimangono in memoria per un determinato periodo di tempo T, durante il quale il db, per richieste esterne, può erogare ottenendo cosi un servizio più veloce.
Il concetto è semplice, il server di database non chiude subito le connessioni al db, al contrario le lascia aperte in attesa che qualcuno possa richiederle. Come si attiva questo meccanismo? Basta modificare attentamente la connection string all’interno del web.config della nostra applicazionie come nel seguente esempio:
<configuration>
<connectionStrings>
<add name="Connessione"
ConnectionString="Server=localhost;Integrated Security=SSPI;Pooling=true;Min Pool Size=1; Max Pool Size=10" />
</connectionStrings>
</configuration>
Sostanzialmente sono stati inseriti tre parametri all’interno della connessione:
- Min Pool Size: numero minimo di connessioni su cui applicare il pooling (quindi cache e riutilizzo);
- Max Pool Size: numero massimo di connessioni su cui applicare il pooling;
- Pooling: con questa proprietà stiamo attivando il meccanismo di pool per la ConnectionString;
Attenzione, Min Pool Size e Max Pool Size, hanno importanza assoluta. Questi due valori vanno impostati dopo un attento studio in quanto determinano proprio l’aumentare o meno delle performance del server sql, se configurati male possono creare più rallentamenti che benefici. Se per esempio ho un’applicazione web in cui sò per certo che avrò un numero di connessioni minime simultanee di 10 persone, logicamente imposterò il mio Min Pool Size = 10.
Spero possa aiutarvi! Enjoy! 
Share on Facebook
Lavorando ogni giorno con applicazioni web, ho pensato di fornire qualche dettaglio in più su come funziona una pagina asp.net, argomento molto interessante per chi come me sviluppa software in cui l’engine è totalmente asincrona per sfruttare al meglio il framework e rendere le applicazioni web più reattive quando il bacino di utenza è elevato (o non si sa mai, anche quando il server web che ospita non è dei migliori!).
Partiamo da una lista dei principali steps di cui si compone la generazione di una pagina web asp.net:
- Inizializzazione
- Costruzione dei controlli
- Gestione dello stato
- Gestione degli eventi (event handler)
- Disegno della pagina (rendering)
- Dove tutto ha inizio.
-
Ma da dove parte tutto? Semplice! Da una richiesta Page Request, il framework, in base alle impostazioni decide se inizializzare nuovamente la pagina o prenderne una copia dalla cache (vi consiglio di leggere qualcosa a riguardo: caching, outputCache); proprietà della pagina come Request e Response vengono impostate, la Request viene inizializzata in base al tipo di richiesta, cioè se la pagina viene caricata per la prima volta o se è in PostBack (tra le proprietà della pagina ce n’è proprio una che si chiama IsPostBack, ovviamente sarebbe opportuno leggere qualcosa anche su questa variabile che differisce come significato dall’argomento outputCahce) ed infine vengono caricate le proprietà relative alla Cultura (ICulture).
- Il caricamento
-
Subito dopo vengono inizializzati tutti i controlli presenti nella pagina, per riassumere: tutti gli elementi html con attributo runat=”server” ed identificati da un ID univoco.
Poi si passa al Caricamento, Load, se la pagina è in PostBack i dati dei controlli vengono caricati dal ViewState (solamente se nella direttiva Page, EnableViewState è impostato a true), in caso contrario viene eseguita la logica descritta dallo sviluppatore.
- La validazione
-
Validation, viene richiamato il metodo di Validazione di ogni controllo per capire se questo ha subito variazioni problematiche. Se la pagina è in PostBack, vengono eseguiti i metodi chiamanti (es. pressione di un bottone a cui è collegato un evento).
- Il disegno
-
Finalmente arriviamo al Disegno vero è proprio, Rendering, attraverso il quale la pagina viene disegnata, un OutputStream carica al suo interno il contenuto HTML generato da ogni controllo presente in essa(si perchè ognuno di essi contiene un metodo che si chiama RenderControl che accetta un HttpTextWriter su cui rilascia codice html per quanto riguarda “se stesso”) e poi di volta in volta per tutti gli altri elementi presenti.
- Il rilascio
-
Alla fine, viene avviata un operazione di “pulizia” (si perchè il framework vuole ordine), cosi si passa al processo di Unload. Una volta che la pagina è stata disegnata ed inviata al richiedente tutte le sue proprietà vengono rilasciate (si parla proprio di Dispose).
Molto importante in questo contesto è il concetto di Event wire-up, ASP.NET cerca di trovare dei metodi che corrispondono ad una denominazione convenzionale (Page_Load, Pag_Init etc.), è possibile attivare o meno questo comportamento (che per Default è lo è già) impostando la proprietà (nella System.Page) AutoEventWireup su true/false.
Con questo breve articolo ho cercato di fornire qualche spiegazione in più, utile durante quei lunghi debug dove delle volte ci riesce davvero difficile capire dove risieda il problema ma più in generale anche per avere più chiarezza sulle strumentazioni che si utilizzano!
Share on Facebook
Commenti recenti