Zła wydajność na platformie Azure dla aplikacji Owin/IIS

Question

Mierzyliśmy niektóre testy wydajności i zauważyłem, że procesor działa dużo czasu w trybie jądra. Chciałbym wiedzieć, dlaczego tak jest.

Aplikacja: to klasyczny Azure Chmura internetowa usługa roli gdzie Owin nasłuchuje pod IIS i sam Owin służy pliki tylko statyczne, które są buforowane w pamięci (więc nie powinno być tylko trochę kara wydajność i everyting powinna być dość szybki). Treść jest kopiowana przez await stream.CopyToAsync(response.Body) do strumienia wyjściowego.

Samo badanie wygląda to w 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) 

(I skróconej próbę uruchomienia 3 minuty po prostu złapać dane, aby pokazać tutaj) Istnieją 3 komputery, które działają tego testu gatling każdy górę do 150 równoczesnych wątków, łącznie do 450 wątków.

Co widzę, że nie ma dużo kodu w jądrze i procesu W3wp nie bierze większość CPU działa:

Schwytany CPU, gdy test się rozpoczął (CPU wzrasta, gdy są nowe wątki dodana)

przechwycone procesora podczas testów prawie przed końcem:

Tryb jądra wygląda całkiem źle i nie jestem pewien, co może spowodować. Nie powinno być prawie żadnych blokad. Czytając, co jeszcze może spowodować tryb wysokiego jądra, odkryłem, że mogą to spowodować DPC. Więc złapałem trochę danych DPC, ale nie jestem pewien, co jest normalne, a co nie. W każdym razie, wykres z maksymalnymi czasami DPC jest również zawarty w sshot.

Vmbus.sys zajmuje najwięcej czasu ze wszystkich DPC. Oznacza to, że instancja Azure nie jest żadnym nagim metalem (nie jest zaskakująca) i że instancja dzieli się mocą komputacji z innymi. Jak rozumiem, vmbus.sys jest odpowiedzialny za komunikację między np. sama karta sieciowa i hostowana instancja HyperV. Czy uruchomienie systemu HyperV może być główną przyczyną niskiej wydajności?

Chciałbym wiedzieć, gdzie szukać i jak dowiedzieć się, co powoduje tryb jądra w mojej sytuacji.

---

Niektóre więcej danych:

Część danych DPC gdy test rozpoczął (podjęta w ciągu 30 sekund):

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 

Część danych DPC gdy test został kończąc (pobrane w 30 sekund):

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 

% DPC Czas od początku do końca testu

też podejrzenia, że ​​wyczerpała sieciowych - tak testów „Pobierz” tak dużo danych, że limity karty sieciowej są osiągnięte. Może to być prawda na końcu testu (gdy jest maksymalna liczba wątków), ale to nie wyjaśnia, dlaczego jest tak dużo czasu w trybie jądra, nawet na początku testu.

Tylko po to, aby pokazać, ile danych jest wysyłanych - objętość wysłanych danych (linia niebieskozielona) jest o 2 rzędy wielkości mniejsza niż pojemność karty sieciowej.

Answer 1

Od IIS 6 wiele żądań są obsługiwane w trybie jądra, który jest na ogół szybciej niż trybie użytkownika.

more on IIS kernel mode

Wydaje się prawdopodobne, że w przypadku gdy zawartość statyczna jest obsługiwane przez tryb pamięci podręcznej jądra, takie, że wnioski te nie wiążą kod trybu użytkownika. W większości przypadków jest to pożądane ze względu na lepsze perf itp

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

Powodzenia!

Answer 2

To może nie pomóc Ci bezpośrednio. ale po przeniesieniu aplikacji do chmury wystąpiły pewne problemy z wydajnością. Proszę znaleźć dyskusję tutaj:

Huge performance drop after moving to Azure

Po wielu dochodzenia w końcu okazało się nasz problem był z mechanizmem Handling Transient wina. Kiedyś pobierał i czytał web.config za każdym razem powodując ogromne użycie procesora, co nie było problemem z tym samym kodem w środowisku innym niż chmura. Poradziliśmy sobie z tym za pomocą wzoru Singleton wokół niego.

Mam nadzieję, że pomoże Ci dowiedzieć się, czy są jakieś problemy z aplikacją.

Pozdrawiam. :)