Ingo Rammer

Iniziamo con un commento goliardico sul ns stato di salute dopo aver dormito qualcosa come 2 ore...

<MessaggioSubliminale>
Orario noto, condizione accettabile, tasso alcolico nella norma: sono fedele, mi sentirei una m***a se lo facessi...
orario indefinito... viaggio dal porto olimpico verso il nulla... OutOfAlcoholicTaxException... stesso personaggio: be insomma il tradimento.. che vuoi che sia... no ma se la baci e basta non è mica tradire... va bene così l'ho fatto un sacco di volte...

ROT[C*]L / *C: "Cab"
</MessaggioSubliminale>

Torniamo alle cose serie se no mi gambizzano :-D

Brev e in ntroduzione sulle best practice da aplicare alle metodoligie di testine e stressing di un'applicazione per essere sicuri che quello che stiamo testando dia dei risultati che siano utili all'analisi di un eventuale problema e/o collo di bottiglia.

Rammer suggerisce un approccio basato su setp per arrivare ad identificare il collo di bottiglia:

- network tracing / sniffing: bell'esempio di uso di Etheral per analizzare i pacchetti scambiati tra server e client alla ricerca di eventuali problemi, il primo test viene fatto su un'applicazione remoting il secondo su una WCF;

- Tracciare l'accesso al db: fondamentale è capire cosa succede dietro le quinte, ci sono situazioni in cui lasciare nelle mani di un tool (leggi DataSet e/o ORM) la generazione del codice SQL è un suicidcio, la seconda cosa fondamentale è ridurre all'osso il locking sulle tabelle;

- il terzo step rigurda la profilazione della memoria, un tool free a CLR Profiler, una nota fondamentale è che non traccia i memory leaks ma semplicemente l'uso della memoria;

Va tutto benissimo, abbiamo seguito tutte le best practice ma la ns applicazione continua ad avere problemi... l'indagine deve spostarsi verso i componenti di terzi parti, Ingo ci fa vedere una demo profilando dei componenti di terze parti con risultati a dir poco allarmanti... quindi okkio ;-)

.m