2017-01-02 11 views
5

Mam prostą aplikację ASP.NET, która zmienia rozmiar obrazów tylko za pomocą ImageResizer i nie robi nic więcej. Do celów testowych wyłączyłem buforowanie dysku, więc obrazy są zmieniane na każde żądanie.Proces pojedynczego pracownika IIS 8.5 a wydajność Web Garden

Kiedy przetestować działanie aplikacji z JMeter otrzymuję następujące średnie czasy reakcji:

  • jednym procesie pracownik, 1 jednoczesnych klientów: ~ 200ms
  • pojedynczy proces roboczy, 10 użytkowników jednoczesnych: ~ 1200ms
  • 4 procesy robocze, 10 jednoczesnych klientów: ~ 300ms

Jak widać, kiedy uruchomić jeden proces roboczy i 10 jednoczesnych klientów, czas reakcji zwiększa dr amatycznie pomimo dostępnych zasobów sprzętowych: użycie procesora podczas testu wydajności wynosi ~ 30%, zużycie pamięci wynosi ~ 150 MB.

Jak omówiono here,

sieci ogrody został zaprojektowany dla jednego powodu - Oferowanie aplikacji że nie są CPU-bound ale wykonać długi bieg zwraca zdolność skalować i nie zużywają wszystkie wątki dostępne w proces roboczy.

To nie wygląda jak moja sprawa.

Więc, nie rozumiem, dlaczego osiągam taki wynik. Spodziewam się, że nawet pojedynczy proces roboczy zapewni akceptowalny czas reakcji, dopóki nie osiągnie limitów zasobów. A 10 równoczesnych klientów zdecydowanie nie jest dużym obciążeniem. Czy ktoś może mi wytłumaczyć, gdzie się mylę?

Moja konfiguracja:

  • Windows Server 2012 R2
  • IIS 8.5 ze wszystkimi ustawieniami domyślnymi (z wyjątkiem maxWorkerThreads)
  • quad-core i3 3.4GHz CPU
  • 16 GB RAM

Moja aplikacja to po prostu pusta aplikacja ASP.NET MVC z ImageResizer, dodana jako this instruction (opcja 3 - Manual I nstallation) i z wtyczką DiskCache wyłączoną w Web.config

+1

Właśnie na podstawie tych liczb podanych przez Ciebie, nie wiedząc nic o ImageResizer, wygląda ImageResizer pracuje rozmiaru operacji w jednym Thr ead, może STA? Ta (spekulacja) mogłaby mieć miejsce, gdyby była oparta na komponencie COM, który nie obsługiwał wielu wątków. – Ben

Odpowiedz

3

Znalazłem odpowiedź dzięki komentarzowi @ Bena.

Problem polega na tym, że ImageResizer jest oparty na GDI + (jak podano na it's site), który zawiera wewnętrzne zamki (szczegółowe informacje znajdują się w pozycjach this i this). Dlatego tak wolno działa w jednym procesie.

Po znalezieniu przyczyny problemu spróbowałem: this solution. Odwoływanie zestawów WPF z aplikacji ASP.NET nie jest prawdopodobnie najlepszym pomysłem, ale jest w porządku do celów testowych.

Teraz mam następujące wyniki, kiedy wykonują te same testy wydajności jak w pytaniu:

  • jeden proces roboczy, 1 jednoczesnego klienta: ~ 90ms
  • pojedynczego procesu roboczego, 10 użytkowników jednoczesnych: ~ 120ms
  • proces pojedynczy pracownik, 40 jednoczesnych klientów: ~ 190ms
  • pojedynczy proces roboczy, 60 jednoczesnych klientów: ~ 400ms
  • pojedynczy proces roboczy, 80 jednoczesnych klientów: ~ 630ms

Jak widać, teraz aplikacja działa znacznie szybciej. Poza tym, jak się początkowo spodziewałem, wykorzystuje prawie wszystkie dostępne zasoby procesora pod dużym obciążeniem.

Tak więc, jeśli przetwarzanie obrazów w aplikacji ASP.NET:

  • nie stosować rozwiązanie oparte GDI +, jeśli można
  • jeśli trzeba użyć GDI +, zwiększenie MaxWorkerProcesses w applicaion ustawienia puli za
Powiązane problemy