Czy Core mvc jest mniej wydajniejszy od mvc 5?

0

Przeprowadzam testy wydajnościowe przy pomocy Jmeter: badam średni czas odpowiedzi requestów i widze że Core MVC na windowsie (IIS EXPRESS) jest zdecydowanie mniej wydajny niż MVC.
W mvc na 1k wyslanych requestow na sekundę nie mam żadnego error, natomiast 1k w MVC Core już otrzymuję errory.
To nie jest tak, że Core jest nowszy i powinien być wydajniejszy?

Pytam bo pewnie gdzieś błędy robię podczas tych pomiarów.

1

Zależy jakiego używasz hosting model, kiedyś Asp.Net Core na windowsie z IISem potrafił działać tylko w trybie out-of-process i działało to mniej więcej tak:

  1. request trafiał do IIS
  2. IIS wstępnie przetwarzał żądanie i przesyłał je do serwera asp.net core (kestrel)
  3. kestrel wykonywał żądanie i obliczał odpowiedź
  4. kestrel przekazywał odpowiedź do iisa
  5. iis odpowiadał klientowi

Więc dwukrotnie musiała zajść komunikacja pomiędzy iisem, a kestrelem (oddzielne procesy).

Z moich obserwacji wynikało, że w takiej konfiguracji faktycznie Asp.Net Core na windowsie działający za IISem był wolniejszy od Asp.Net Mvc 5 (tam całe żądanie wykonywane było bezpośrednio przez IIS).

W którejś wersji Asp.Net Core dodali możliwość ustawienia modelu in-process, gdzie Asp.Net Core nie odpala kestrela w oddzielnym procesie, tylko zrobiona jest oddzielna implementacja serwera, który odpalany jest wewnątrz procesu IISa.

3

Słabo znam się na testach wydajnościowych, natomiast wątpie, żeby .NET osiagał porównywalne wyniki do .NET Core. https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/. Podobno w wersji 3.0 jest znaczna poprawa względem 2.2 https://twitter.com/ben_a_adams/status/1115929774147477505 Stawiam, że twoje środowisko testowe jest błędnie postawione.

0
sharper_99 napisał(a):

Słabo znam się na testach wydajnościowych, natomiast wątpie, żeby .NET osiagał porównywalne wyniki do .NET Core. https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/. Podobno w wersji 3.0 jest znaczna poprawa względem 2.2 https://twitter.com/ben_a_adams/status/1115929774147477505 Stawiam, że twoje środowisko testowe jest błędnie postawione.

Tylko on nie pisał o porównaniu wydajności .NET do .NET Core a Asp.Net Mvc 5 do Asp.Net Core. A gdy korzystał z pełnego .NET to jak najbardziej nawet pomimo poprawnego skonfigurowania środowiska Asp.Net Mvc mógł być szybszy od Asp.Net Core z powodów, które wymieniłem w poście wyżej.

To całe chwalenie się wydajnością Asp.Net Core na samym początku też było trochę pod publiczkę, bo wszystkie testy były przeprowadzane na Kestrelu, a do wersji 2.2 Asp.Net Core sami pisali, że Kestrel nie jest gotowy żeby wystawiać go na internet i potrzebny jest reverse proxy. No a z IIS jako reverse proxy to już tak kolorowo nie było :P

3

Taki drobny offtopic, zostanie dla potomności, przetestowałem najtańszy vps od OVH, 2 GB RAM, 1 CPU Haswell 2,4GHz
Cel testów : endpoint generujący token, https/http2/gzip, asp net core, za reverse proxy apache, bez async/await
Wynik: 200 req/seq

RAM: 40%
CPU: 100%, apache (40%), dotnet (30%), telegraf(15%), system (10%), postgresql(5%)

net core 2.2, ubuntu, Workstation GC
obciążenie: https://loader.io/
metryki: telegraf + influxdb

zbieram dużo różnorodnych metryk, więc pewnie bez nich wynik byłby jeszcze lepszy.

0

A z nginx zamiast Apache?

0

Stuningowałem trochę ustawienia serwera, okazało się że apache jest bardzo czuły na to co tam jest wpisane i defaulty są bardzo niskie, zmniejszyłem też liczbę zbieranych metryk(analiza real time logu apache na tym samym serwerze co apache była kiepskim pomysłem).
Testuje endpoint generujący token JWT, więc z bazy jest wyciągany tylko jeden rekord.

liczba jednoczesnych połaczeń 400 500 600 700
Sync - Response Times Average (ms) 632 794 943 1215
Sync - Req/s 635 642 642 602
Async - Response Times Average (ms) 673 812 989 1285
Async - Req/s 608 623 608 590

metryki przy 500 połączeniach
CPU : 100% (dotnet 66%, postgresql 13%, apache 10%)
RAM: 55%

nginx nigdy wcześniej nie stawiałem, więc to trochę potrwa, pierwszeństwo ma endpoint zwracający więcej danych z bazy.

1

Powtórzyłem testy obciążeniowe po migracji na net core 3.0, konfiguracja serwera dokładnie ta sama, api ciągle korzysta z biblioteki od Newtonsoft do jsona.

liczba jednoczesnych połączeń 400 500 600 700
Sync - Response Times Average (ms) 545 703 850 1021
Sync - Req/s 728 703 697 675
Async - Response Times Average (ms) 651 802 947 1096
Async - Req/s 609 618 626 632

wersja synchroniczna jest wydajniejsza o 10%-15%
wersja asynchroniczna jedynie poprawa przy większej liczbie jednoczesnych połączeń na sekundę

i wygląda na to że pojawił się wyciek pamięci po migracji :(

1 użytkowników online, w tym zalogowanych: 0, gości: 1