Prestazioni errate su Azure per l'applicazione Owin/IIS

Question

Abbiamo misurato alcuni test di esecuzione e ho notato che la CPU impiega molto tempo in modalità kernel. Mi piacerebbe sapere perché è quello.

L'applicazione: è classico Azure cloud ruolo di servizio web in cui Owin è in ascolto sotto l'IIS e Owin si serve file solo statici che vengono memorizzati nella cache in memoria (quindi non ci dovrebbe essere solo una penalizzazione delle prestazioni poco e everyting dovrebbe essere abbastanza veloce). Il contenuto viene copiato tramite await stream.CopyToAsync(response.Body) per trasmettere il flusso.

La prova stessa si presenta così in gatling:

val openLoginSet = exec(http("ROOT") 
     .get("/") 
     .headers(Headers105Test2.headers_0) 
     .resources(
     http("MED: arrow-down-small.png").get(uriIconAssets + "/arrow-down-small.png").headers(Headers105Test2.headers_1), 
     http("MED: arrow-up-small.png").get(uriIconAssets + "/arrow-up-small.png").headers(Headers105Test2.headers_1), 
     http("MED: close-medium.png").get(uriIconAssets + "/close-medium.png").headers(Headers105Test2.headers_1), 
     http("MED: decline-medium.png").get(uriIconAssets + "/decline-medium.png").headers(Headers105Test2.headers_1), 
     http("MED: help-medium.png").get(uriIconAssets + "/help-medium.png").headers(Headers105Test2.headers_1), 
     http("MED: submit-medium.png").get(uriIconAssets + "/submit-medium.png").headers(Headers105Test2.headers_1), 
     http("MED: delete-medium.png").get(uriIconAssets + "/delete-medium.png").headers(Headers105Test2.headers_1), 
     http("MED: en-us.js").get("/en-us.js").headers(Headers105Test2.headers_8), 
     http("MED: cloud_logo_big.png").get("/assets/cloud_logo_big.png").headers(Headers105Test2.headers_1), 
     http("MED: favicon.ico").get("/favicon.ico").headers(Headers105Test2.headers_0)) 

val httpProtocol = http 
    .baseURL("https://myurl.com") 
    .inferHtmlResources() 

val openLoginSenario = scenario("OpenOnly").exec(repeat(400, "n") { 
    exec(openLoginSet).pause(3,6) 
}) 

setUp(openLoginSenario.inject(rampUsers(150) over (3 minutes))) 
    .protocols(httpProtocol) 
    .maxDuration(3 minutes) 

(ho accorciato il test per eseguire 3 minuti solo per catturare i dati per mostrare qui) Ci sono 3 computer che eseguono questo test gatling, ciascuno fino a 150 thread simultanei, quindi 450 thread in totale.

Quello che vedo è che c'è un sacco esecuzione di codice in kernel e il processo di W3wp non prende la maggior parte della CPU:

CPU Catturato quando il test appena iniziato (la CPU è in aumento quando sono nuove discussioni aggiunto):

CPU catturato quando le prove sono quasi prima estremità:

La modalità kernel sembra piuttosto male e non sono sicuro di cosa potrebbe causarlo. Non dovrebbero esserci quasi serrature coinvolte. Durante la lettura di cos'altro potrebbe causare la modalità kernel alta, ho scoperto che i DPC potrebbero causarlo. Quindi ho acquisito anche alcuni dati DPC, ma non sono sicuro di cosa sia normale e cosa no. Ad ogni modo, anche il grafico con DPC max times è incluso nel sshot.

Il vmbus.sys richiede il tempo più significativo da tutti i DPC. Ciò significa che l'istanza di Azure non è un semplice metallo (non sorprendente) e che l'istanza condivide il suo potere computazionale con altri. A quanto ho capito, vmbus.sys è responsabile per la comunicazione tra ad es. scheda di rete stessa e l'istanza HyperV ospitata. L'esecuzione di HyperV potrebbe essere la causa principale delle basse prestazioni?

Mi piacerebbe sapere dove guardare e come scoprire che cosa causa la modalità kernel nella mia situazione.

---

Qualche altro dato:

Parte dei dati DPC quando il test ha iniziato (prelevato nelle 30 sec):

Total = 17887 for module vmbus.sys 
Elapsed Time, >  0 usecs AND <=  1 usecs, 137, or 0.77% 
Elapsed Time, >  1 usecs AND <=  2 usecs, 2148, or 12.01% 
Elapsed Time, >  2 usecs AND <=  4 usecs, 3941, or 22.03% 
Elapsed Time, >  4 usecs AND <=  8 usecs, 2291, or 12.81% 
Elapsed Time, >  8 usecs AND <=  16 usecs, 5182, or 28.97% 
Elapsed Time, >  16 usecs AND <=  32 usecs, 3305, or 18.48% 
Elapsed Time, >  32 usecs AND <=  64 usecs, 786, or 4.39% 
Elapsed Time, >  64 usecs AND <=  128 usecs,  85, or 0.48% 
Elapsed Time, >  128 usecs AND <=  256 usecs,  6, or 0.03% 
Elapsed Time, >  256 usecs AND <=  512 usecs,  1, or 0.01% 
Elapsed Time, >  512 usecs AND <=  1024 usecs,  2, or 0.01% 
Elapsed Time, >  1024 usecs AND <=  2048 usecs,  0, or 0.00% 
Elapsed Time, >  2048 usecs AND <=  4096 usecs,  1, or 0.01% 
Elapsed Time, >  4096 usecs AND <=  8192 usecs,  2, or 0.01% 
Total,             17887 

Parte dei dati DPC quando il test stava finendo (preso in 30 sec):

Total = 141796 for module vmbus.sys 
Elapsed Time, >  0 usecs AND <=  1 usecs, 7703, or 5.43% 
Elapsed Time, >  1 usecs AND <=  2 usecs, 21075, or 14.86% 
Elapsed Time, >  2 usecs AND <=  4 usecs, 17301, or 12.20% 
Elapsed Time, >  4 usecs AND <=  8 usecs, 38988, or 27.50% 
Elapsed Time, >  8 usecs AND <=  16 usecs, 32028, or 22.59% 
Elapsed Time, >  16 usecs AND <=  32 usecs, 11861, or 8.36% 
Elapsed Time, >  32 usecs AND <=  64 usecs, 7034, or 4.96% 
Elapsed Time, >  64 usecs AND <=  128 usecs, 5038, or 3.55% 
Elapsed Time, >  128 usecs AND <=  256 usecs, 606, or 0.43% 
Elapsed Time, >  256 usecs AND <=  512 usecs,  53, or 0.04% 
Elapsed Time, >  512 usecs AND <=  1024 usecs,  26, or 0.02% 
Elapsed Time, >  1024 usecs AND <=  2048 usecs,  11, or 0.01% 
Elapsed Time, >  2048 usecs AND <=  4096 usecs,  10, or 0.01% 
Elapsed Time, >  4096 usecs AND <=  8192 usecs,  53, or 0.04% 
Elapsed Time, >  8192 usecs AND <= 16384 usecs,  3, or 0.00% 
Elapsed Time, > 16384 usecs AND <= 32768 usecs,  1, or 0.00% 
Elapsed Time, > 32768 usecs AND <= 65536 usecs,  5, or 0.00% 
Total,            141796 

% Tempo DPC dall'inizio alla fine della prova

Abbiamo anche il sospetto che abbiamo raggiunto i limiti della rete - in modo che le prove di 'scaricare' così tanti dati che i limiti della scheda di rete sono raggiunti. Questo potrebbe essere vero durante la fine del test (quando c'è il numero massimo di thread), ma questo non spiega perché ci sia così tanto tempo in modalità kernel anche all'inizio del test.

Solo per mostrare la quantità di dati inviati: il volume dei dati inviati (linea ciano) è di 2 ordini di grandezza inferiore alla capacità della scheda di rete.

Answer 1

Dal IIS 6 molte richieste sono gestite in modalità kernel, che è generalmente più veloce di modalità utente.

more on IIS kernel mode

Sembra probabile che nel tuo caso il contenuto statico viene gestito dalla cache in modalità kernel, in modo tale che tali richieste non coinvolgono il codice in modalità utente. Nella maggior parte dei casi questo è desiderabile a causa di una migliore perf, ecc

more on content that can/cannot be handled by kernel mode

more on configuring/monitoring IIS output caching to verify its use in your test

still more

Buona fortuna!

Answer 2

Questo potrebbe non essere di aiuto direttamente. ma abbiamo avuto alcuni problemi di prestazioni dopo aver spostato un'applicazione nel cloud. Si prega di trovare la discussione qui:

Huge performance drop after moving to Azure

Dopo un sacco di ricerca al fine abbiamo scoperto il nostro problema era con il meccanismo di gestione transitoria guasto. Andava e leggeva il web.config ogni volta causando un enorme utilizzo della CPU che non era un problema con lo stesso codice in ambiente non cloud. Lo abbiamo gestito utilizzando un pattern Singleton attorno ad esso.

Spero che ti aiuti a scoprire se ci sono tali problemi con l'applicazione.

Cheers. :)