Strategie per l'analisi delle prestazioni di un'applicazione Web ASP.NET in esecuzione su .NET 4

7

Sto cercando di confrontare le prestazioni di un'applicazione che è stata recentemente convertita da .NET2 in .NET4. Dai miei test di perfomance sembra che, sebbene i tempi di risposta alle pagine siano generalmente un po 'migliori con .NET4, sono inferiori all'equivalente sotto .NET2 quando sono sotto stress.

Da quello che ho visto finora è che sotto .NET4, il processore (4 core) si satura prima e IIS usa forse il 20% di thread in più.

Che cosa dovrei guardare avanti per avanzare nella mia comprensione di cosa potrebbe causare queste differenze?

    
posta Tom Carter 25.09.2015 - 10:57
fonte

2 risposte

1

È difficile dire dal livello di dettaglio che fornisci, che cosa è esattamente il caso. Quando stai dicendo

that has recently been converted from .NET2 to .NET4.

questo potrebbe significare cose diverse: da »Il compilatore era solo un compilatore .NET4 e compilato per quel target« a ». Ehi, ci sono simili sottigliezze in termini di Parallel Programming. Risolviamo riscrivi tutto «

E con quest'ultimo in testa, forse (!) questo è il motivo delle tue osservazioni

they are worse than the equivalent under .NET2 when under stress.

o

From what i've seen so far is that under .NET4, the processor (4 cores) becomes saturated earlier and IIS uses perhaps 20% more threads

Ma nessuno dei due ha a che fare con il passaggio da .NET2 a .NET4 ma con l'ossessione del parallelismo. C'è un bell'articolo da Zeroturnaround per Java-People che erano presentato di recente a stream paralleli che è equivalente a PLINQ sotto .Net.

Cito l'ultimo paragrafo

Parallel streams are unpredictable and complex to use correctly. Almost any use of parallel streams can affect the performance of other unrelated system components in an unpredictable way. I have no doubt that there are people who can manage to use them to their benefit, clearly and correctly. However, I’d think twice before typing stream.parallel() into my code and would look twice when reviewing the code containing it.

Ulteriori strategie

C'è una sola strategia di successo

Misura, non indovinare

La maggior parte delle volte, quando si affrontano problemi di prestazioni, le persone iniziano a indovinare »Oh, so dove si trova il collo di bottiglia: deve essere X . Ho sempre pensato che X fosse un cattivo design ... «Smetti di indovinare il gioco e misura. Potrebbero esserci un sacco di motivi, del perché le prestazioni di un'applicazione sono lente.

Ci sono diversi modi / livelli di misurazione: a partire dal semplice logging di timestamp per alcune azioni fino all'utilizzo di strumenti come Glimpse , Nuova reliquia o AppDynamics .

Prendi ciò che si adatta alle tue esigenze / budget. Ho lavorato con AppDynamics per JAVA ed è stato un ottimo strumento.

Se noti i colli di bottiglia real , sei in grado di prendere una decisione informata su come deve essere modificato il codice.

    
risposta data 08.05.2016 - 15:28
fonte
0

Su un sistema operativo Win32 / Win64, l'eccellente, open source, ProcessHacker ti fornirà una visione molto dettagliata dei processi, thread, moduli, persino assembly di codice gestiti caricati ed eseguiti in qualsiasi albero del processo, insieme all'utilizzo della CPU e della memoria, inclusi tutti i tipi di maniglie del sistema operativo che usano, ecc.

'HTH,

    
risposta data 09.03.2016 - 07:17
fonte

Leggi altre domande sui tag