Jedno z moich ulubionych pytań na rozmowie kwalifikacyjnej brzmi: „Co mówią ci takie słowa jak   i   ?”, ponieważ otwiera to okazję do ciekawej dyskusji z osobą udzielającą wywiadu… Albo nie, ponieważ poruszają ten temat. Moim zdaniem, zrozumienie, dlaczego stosujemy tę technikę, jest niezwykle ważne. async await  Mam wrażenie, że wielu programistów woli polegać na stwierdzeniu, że „to najlepsza praktyka” i stosować metody asynchroniczne w ciemno.  W tym artykule pokazano różnice pomiędzy metodami asynchronicznymi i synchronicznymi w praktyce.  Narzędzia  Aplikacja .NET Web API (cel testowy)  2 bazy danych Azure SQL  2 Azure App Service w systemie Windows (obsługuje aplikację)  Azure App Insights (do zbierania metryk)  framework   (do symulacji obciążenia użytkownika). Locust  Konfiguracja   Przeprowadzę test porównawczy w następujący sposób. Dwie niezależne instancje Locust są uruchomione na dwóch maszynach. Instancje Locust symulują użytkownika, który wykonuje następujące czynności:  Użytkownik z hosta locust 1 trafia do   punktu końcowego   otrzymuje odpowiedź i pozostaje bezczynny przez 0,5–1 sekundy (dokładne opóźnienie jest losowe). Powtarza się do końca eksperymentu. synchronicznego usługi App Service 1,  Użytkownik z hosta Locust 2 zachowuje się dokładnie tak samo, z jedną różnicą — trafia do   punktu końcowego  asynchronicznego usługi App Service 2.  Pod maską każda usługa App Service łączy się z własną bazą danych i wykonuje zapytanie SELECT, które trwa pięć sekund i zwraca kilka wierszy danych. Zobacz kod kontrolera poniżej, aby uzyskać odniesienia. Użyję Dappera, aby wykonać wywołanie do bazy danych. Chciałbym zwrócić uwagę na fakt, że asynchroniczny punkt końcowy również wywołuje bazę danych asynchronicznie (   ).  QueryAsync<T>  Warto dodać, że wdrażam ten sam kod w obu usługach aplikacyjnych.  Podczas testu liczba użytkowników rośnie równomiernie do liczby docelowej (   ). Prędkość wzrostu jest kontrolowana przez parametr   (liczba unikalnych użytkowników dołączających na sekundę) — im wyższa liczba, tym szybciej dodawani są użytkownicy.   jest ustawiona na 10 użytkowników/s dla wszystkich eksperymentów. Liczba użytkowników Spawn Rate Szybkość odradzania  Czas trwania każdego eksperymentu jest ograniczony do 15 minut.  Szczegóły dotyczące konfiguracji maszyny można znaleźć w części artykułu zatytułowanej Dane techniczne.  Metryka    — pokazuje liczbę żądań, które aplikacja faktycznie przetworzyła i zwróciła kod statusu. żądania na minutę    — pokazuje liczbę wątków zużywanych przez usługę aplikacji. liczba wątków   mediana czasu reakcji, ms  Czerwone linie odnoszą się odpowiednio do asynchroniczności, a niebieskie — do punktu końcowego synchronicznego.  To tyle o teorii. Zacznijmy.   Eksperyment nr 1    : 75 (na usługę) liczba użytkowników  Widzimy, że oba punkty końcowe działają podobnie — obsługują około 750 żądań na minutę, a mediana czasu odpowiedzi wynosi 5200 ms.   Najbardziej fascynującym wykresem w tym eksperymencie jest trend wątków. Można zobaczyć znacznie wyższe liczby dla synchronicznego punktu końcowego (niebieski wykres) — ponad 100 wątków!   To jednak jest oczekiwane i zgodne z teorią — gdy przychodzi żądanie i aplikacja wykonuje wywołanie do bazy danych, wątek jest blokowany, ponieważ musi czekać na zakończenie podróży w obie strony. Dlatego gdy przychodzi kolejne żądanie, aplikacja musi utworzyć nowy wątek, aby je obsłużyć.  Czerwony wykres — liczba wątków asynchronicznych punktów końcowych — pokazuje inne zachowanie. Gdy przychodzi żądanie i aplikacja wykonuje wywołanie do bazy danych, wątek wraca do puli wątków zamiast być blokowanym. Dlatego gdy przychodzi kolejne żądanie, ten wolny wątek jest ponownie używany. Pomimo wzrostu liczby żądań przychodzących, aplikacja nie wymaga żadnych nowych wątków, więc ich liczba pozostaje taka sama.  Warto wspomnieć o 3. metryce —   . Oba punkty końcowe wykazały ten sam wynik — 5200 ms. Nie ma więc różnicy pod względem wydajności.  medianie czasu reakcji  Teraz nadszedł czas, aby podnieść stawkę.  Eksperyment nr 2    : 150 liczba użytkowników  Podwoiliśmy obciążenie. Asynchroniczny punkt końcowy radzi sobie z tym zadaniem pomyślnie — jego szybkość   oscyluje wokół 1500. Synchroniczny brat ostatecznie osiągnął porównywalną liczbę 1410. Ale jeśli spojrzysz na poniższy wykres, zobaczysz, że zajęło to 10 minut! żądania na minutę  Powodem jest to, że synchroniczny punkt końcowy reaguje na przybycie nowego użytkownika, tworząc kolejny wątek, ale użytkownicy są dodawani do systemu (przypominamy, że   wynosi 10 użytkowników/s) szybciej, niż serwer WWW jest w stanie się dostosować. Dlatego na samym początku ustawiono w kolejce tak wiele żądań.  współczynnik odradzania się  Nie jest zaskoczeniem, że metryka   nadal wynosi około 34 dla asynchronicznego punktu końcowego, podczas gdy wzrosła ze 102 do 155 dla synchronicznego.   spadła podobnie do szybkości   — synchroniczny czas odpowiedzi był znacznie wyższy na początku eksperymentu. Gdybym trzymał test przez 24 godziny, mediana liczb stałaby się równa.  liczby wątków Mediana czasu odpowiedzi żądania na minutę  Eksperyment nr 3    : 200 liczba użytkowników  Trzeci eksperyment ma na celu potwierdzenie tendencji ujawnionych podczas drugiego — możemy zaobserwować dalszą degradację punktu końcowego synchronizacji.   Wniosek  Korzystanie z operacji asynchronicznych zamiast synchronicznych nie poprawia bezpośrednio wydajności ani doświadczenia użytkownika. Po pierwsze, zwiększa stabilność i przewidywalność pod presją. Innymi słowy, podnosi próg obciążenia, dzięki czemu system może przetworzyć więcej, zanim ulegnie degradacji.  Załącznik nr 1. Szczegóły techniczne  Azure App Service: B1, 100   , pamięć 1,75 Gb, równoważnik obliczeniowy serii A. ACU  Baza danych Azure SQL: Standard S4: 200 jednostek DTU, pamięć masowa 500 Mb.  Ustawienia połączenia SQL: Maksymalny rozmiar puli = 200.  Załącznik nr 2. Notatki  Aby uzyskać najczystsze wyniki testów, powinienem uruchomić testy z dwóch maszyn wirtualnych znajdujących się w tej samej sieci, w której znajdują się docelowe usługi aplikacji.  Założyłem jednak, że opóźnienie sieciowe wpłynie na obie aplikacje w mniej więcej podobny sposób. Dlatego nie może zagrozić głównemu celowi — porównaniu zachowania metod asynchronicznych i synchronicznych.   Załącznik nr 3. Eksperyment bonusowy  Co zrobiłem, aby zmusić synchroniczny punkt końcowy do działania niemal tak asynchronicznie i przedstawić poniższy wykres (warunki eksperymentu są takie same, jak w trzecim eksperymencie — 200 użytkowników)? 

Read My Stories

Buy Me a Coffee

Ten dźwięk jest produkowany w oryginalnym języku historii!

Async vs Sync Benchmark (.NET): różnica między metodami asynchronicznymi i synchronicznymi

About Author

UWAGI

ZAWIEŚĆ TAGI

ARTYKUŁ TEN ZOSTAŁ PREZENTOWANY W

Related Stories

Reach More Readers! BOOST Your Story on HackerNoon

Pleasures of the telescope by Garrett Putman Serviss - Table of Links

Everything You Need to Know About HackerNoon’s Proof of Usefulness Hackathon

Listen to Tech Brief Podcasts on Your Headphones: Stay Connected to HackerNoon Anywhere, Anytime

Reach More Readers! BOOST Your Story on HackerNoon

Pleasures of the telescope by Garrett Putman Serviss - Table of Links

Everything You Need to Know About HackerNoon’s Proof of Usefulness Hackathon

Listen to Tech Brief Podcasts on Your Headphones: Stay Connected to HackerNoon Anywhere, Anytime

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps