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

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"

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