Jedna z mojich obľúbených otázok na pohovore je „Čo vám hovoria slová ako   a   ?“ pretože to otvára príležitosť na zaujímavú diskusiu s opýtaným... Alebo nie, pretože sa vznášajú na túto tému. Podľa môjho názoru je veľmi dôležité pochopiť, prečo používame túto techniku. async wait  Mám pocit, že mnohí vývojári sa radšej spoliehajú na vyhlásenie „je to najlepší postup“ a slepo používajú asynchrónne metódy.  Tento článok ukazuje rozdiel medzi asynchrónnymi a synchrónnymi metódami v praxi.  Nástroje  Aplikácia .NET Web API (cieľ testu)  2 databázy Azure SQL  2 Azure App Service v systéme Windows (hosťuje aplikáciu)  Azure App Insights (na zhromažďovanie metrík)    rámec (na simuláciu užívateľského zaťaženia). kobylkový  Konfigurácia   Spustím benchmark nasledujúcim spôsobom. Na dvoch počítačoch bežia dve nezávislé inštancie kobyliek. Inštancie Locustu simulujú používateľa, ktorý robí nasledovné:  Používateľ z hostiteľa kobyliek 1 zasiahne   koncový bod   dostane odpoveď a zostane nečinný 0,5 až 1 sekundy (presné časové oneskorenie je náhodné). Opakuje sa až do konca experimentu. synchrónny služby App Service 1,  Používateľ z hostiteľa kobylky 2 sa správa presne rovnako, len s jedným rozdielom – narazí na   koncový bod  asynchrónny App Service 2.  Pod kapotou sa každá App Service pripojí k svojej vlastnej databáze a vykoná SELECT dotaz, ktorý trvá päť sekúnd a vráti niekoľko riadkov údajov. Odkazy nájdete v kóde ovládača nižšie. Použijem Dapper na zavolanie do databázy. Chcel by som upriamiť vašu pozornosť na skutočnosť, že asynchrónny koncový bod volá databázu asynchrónne (   ).  QueryAsync<T>  Stojí za to dodať, že nasadzujem rovnaký kód do oboch služieb aplikácie.  Počas testu sa počet používateľov rovnomerne rozrastie na cieľové číslo (   ). Rýchlosť rastu je riadená parametrom   (počet jedinečných používateľov, ktorí sa môžu pripojiť za sekundu) – čím vyššie číslo, tým rýchlejšie sa používatelia pridávajú.   je nastavená na 10 používateľov/s pre všetky experimenty. Počet používateľov Spawn Rate Rýchlosť spúšťania  Všetky experimenty sú obmedzené na 15 minút.  Podrobnosti o konfigurácii stroja nájdete v časti Technické podrobnosti v článku.  Metriky    – zobrazuje počet žiadostí, ktoré aplikácia skutočne spracovala a vrátila stavový kód. žiadostí za minútu    – zobrazuje počet vlákien, ktoré služba aplikácie spotrebuje. počet vlákien   stredná doba odozvy, ms  Červené čiary odkazujú na asynchrónne a modré čiary na synchrónny koncový bod.  To je o teórii. Začnime.   Experiment č. 1    : 75 (na službu) počet používateľov  Vidíme, že oba koncové body fungujú podobne – spracovávajú približne 750 požiadaviek za minútu so strednou dobou odozvy 5200 ms.   Najfascinujúcejším grafom v tomto experimente je trend vlákna. Môžete vidieť výrazne vyššie čísla pre synchrónny koncový bod (modrý graf) – viac ako 100 vlákien!   To sa však očakáva a zodpovedá to teórii – keď príde požiadavka a aplikácia zavolá do databázy, vlákno sa zablokuje, pretože musí čakať na dokončenie spiatočnej cesty. Preto, keď príde ďalšia požiadavka, aplikácia musí vytvoriť nové vlákno, aby ju zvládla.  Červený graf – počet vlákien asynchrónneho koncového bodu – dokazuje odlišné správanie. Keď príde požiadavka a aplikácia zavolá do databázy, vlákno sa namiesto zablokovania vráti do oblasti vlákien. Preto, keď príde ďalšia požiadavka, toto bezplatné vlákno sa znova použije. Napriek narastajúcemu počtu prichádzajúcich požiadaviek aplikácia nevyžaduje žiadne nové vlákna, takže ich počet zostáva rovnaký.  Za zmienku stojí 3. metrika –   . Oba koncové body ukázali rovnaký výsledok – 5200 ms. Z hľadiska výkonu teda nie je žiadny rozdiel.  stredná doba odozvy  Teraz je čas zdvihnúť stávky.  Experiment č. 2    : 150 počet užívateľov  Záťaž sme zdvojnásobili. Asynchrónny koncový bod túto úlohu úspešne zvláda – rýchlosť jeho   sa pohybuje okolo 1500. Synchrónny brat nakoniec dosiahol porovnateľné číslo 1410. Ak sa však pozriete na graf nižšie, uvidíte, že to trvalo 10 minút! požiadaviek za minútu  Dôvodom je, že synchrónny koncový bod reaguje na príchod nového používateľa vytvorením ďalšieho vlákna, ale používatelia sú pridávaní do systému (len pre pripomenutie, že   je 10 používateľov/s) rýchlejšie, než sa dokáže prispôsobiť webový server. Preto hneď na začiatku stálo v rade toľko žiadostí.  rýchlosť spúšťania  Nie je prekvapením, že metrika   je stále okolo 34 pre asynchrónny koncový bod, zatiaľ čo sa zvýšila zo 102 na 155 pre synchrónny koncový bod.   sa znížil podobne ako rýchlosť   – čas synchrónnej odozvy bol na začiatku experimentu oveľa vyšší. Ak by som test nechal 24 hodín, stredné čísla by boli párne.  počtu vlákien Stredný čas odozvy požiadavky za minútu  Experiment č. 3    : 200 počet užívateľov  Tretí experiment je určený na preukázanie trendov odhalených počas druhého – môžeme vidieť ďalšiu degradáciu synchrónneho koncového bodu.   Záver  Používanie asynchrónnych operácií namiesto synchrónnych operácií priamo nezlepšuje výkon ani používateľskú skúsenosť. Po prvé, zvyšuje stabilitu a predvídateľnosť pod tlakom. Inými slovami, zvyšuje prah zaťaženia, takže systém môže spracovať viac, než dôjde k degradácii.  Príloha č. Technické detaily  Azure App Service: B1, 100   , 1,75 Gb pamäť, výpočtový ekvivalent série A. ACU  Azure SQL Database: Standard S4: 200 DTU, 500 Mb úložisko.  Nastavenia pripojenia SQL: Max Pool Size=200.  Príloha č. 2. Poznámky  Na dosiahnutie najčistejšieho výsledku testu by som mal spustiť testy z 2 virtuálnych počítačov umiestnených v rovnakej sieti, v ktorej sa nachádzajú cieľové služby aplikácií.  Predpokladal som však, že oneskorenie siete ovplyvní obe aplikácie viac-menej podobným spôsobom. Preto nemôže ohroziť hlavný cieľ — porovnanie toho, ako sa správajú asynchrónne a synchrónne metódy.   Dodatok č. 3. Bonusový experiment  Čo som hackol, aby som prinútil synchrónny koncový bod vykonávať takmer rovnako asynchrónne a vykreslil graf nižšie (podmienky experimentu sú rovnaké ako v treťom – 200 používateľov)? 

Read My Stories

Buy Me a Coffee

Tento zvuk je vyrobený v pôvodnom jazyku príbehu!

Async vs Sync Benchmark (.NET): Rozdiel medzi asynchrónnymi a synchrónnymi metódami

About Author

KOMENTÁRE

ZAVISTE ŠTÍTKY

TENTO ČLÁNOK BOL PREDSTAVENÝ V

Related Stories

When Blood Told

112 Stories To Learn About Hackernoon Community

Mutmut: a Python mutation testing system

Behavior of a shapely Spider

When Blood Told

112 Stories To Learn About Hackernoon Community

Mutmut: a Python mutation testing system

Behavior of a shapely Spider

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps