Az egyik kedvenc interjúkérdésem: „Mit mondanak neked az olyan szavak, mint   és   ?” mert ez lehetőséget ad egy érdekes beszélgetésre egy interjúalannyal… Vagy nem, mert lebegnek ebben a témában. Véleményem szerint drasztikusan fontos megérteni, miért használjuk ezt a technikát. az async a wait  Úgy érzem, sok fejlesztő szívesebben hagyatkozik az „ez a legjobb gyakorlat” kijelentésre, és vakon használ aszinkron módszereket.  Ez a cikk bemutatja az aszinkron és a szinkron módszerek közötti különbséget a gyakorlatban.  Eszközök  .NET Web API alkalmazás (teszt cél)  2 Azure SQL Databases  2 Azure App Service Windows rendszeren (az alkalmazást tárolja)  Azure App Insights (mérőszámok gyűjtéséhez)    keretrendszer (a felhasználói terhelés szimulálására). sáska  Konfiguráció   A benchmarkot a következő módon fogom lefuttatni. Két független sáska-példány fut két gépen. A Locust példányok olyan felhasználót szimulálnak, aki a következőket teszi:  Az 1. sáskahoszt felhasználója eléri az 1. App Service   végpontját   megkapja a választ, és 0,5–1 másodpercig tétlen marad (a pontos késleltetés véletlenszerű). Ismétlés a kísérlet végéig. szinkron ,  A 2-es sáskahoszt felhasználója pontosan ugyanúgy viselkedik, egyetlen különbséggel – eléri az App Service 2   végpontját  aszinkron .  A motorháztető alatt minden App Service csatlakozik a saját adatbázisához, és végrehajt egy SELECT lekérdezést, amely öt másodpercig tart, és néhány adatsort ad vissza. Lásd alább a vezérlő kódját a hivatkozásokért. Dapperrel hívom fel az adatbázist. Szeretném felhívni a figyelmet arra, hogy az aszinkron végpont aszinkron módon is hívja az adatbázist (   ).  QueryAsync<T>  Érdemes hozzátenni, hogy ugyanazt a kódot telepítem mindkét alkalmazásszolgáltatásra.  A teszt során a felhasználók száma egyenletesen nő a célszámra (   ). A növekedés sebességét a   paraméter szabályozza (másodpercenként csatlakozó egyedi felhasználók száma) – minél nagyobb ez a szám, annál gyorsabban kerülnek hozzáadásra a felhasználók. A   10 felhasználó/s minden kísérletnél. Users Number Spawn Rate megjelenési sebesség  Minden kísérlet 15 percre korlátozódik.  A gép konfigurációs részleteit a cikk Műszaki részletek szakaszában találja.  Mérések    – megmutatja azoknak a kéréseknek a számát, amelyeket az alkalmazás ténylegesen feldolgozott, és állapotkódot adott vissza. kérések percenként    – az alkalmazásszolgáltatás által felhasznált szálak számát mutatja. szálak száma   medián válaszidő, ms  A piros vonalak az aszinkron, a kék vonalak pedig a szinkron végpontra utalnak.  Ennyit az elméletről. Kezdjük.   1. kísérlet    : 75 (szolgáltatásonként) felhasználók száma  Láthatjuk, hogy mindkét végpont hasonlóan teljesít – percenként körülbelül 750 kérést kezel, 5200 ms medián válaszidővel.   Ebben a kísérletben a leglenyűgözőbb grafikon egy száltrend. A szinkron végpontnál lényegesen magasabb számokat láthat (kék grafikon) – több mint 100 szál!   Ez azonban várható, és megfelel az elméletnek – amikor beérkezik egy kérés, és az alkalmazás felhívja az adatbázist, a szál blokkolva lesz, mert meg kell várnia a körút befejezését. Ezért amikor újabb kérés érkezik, az alkalmazásnak új szálat kell létrehoznia a kezeléséhez.  A piros grafikon – az aszinkron végponti szálak száma – eltérő viselkedést bizonyít. Amikor beérkezik egy kérés, és az alkalmazás felhívja az adatbázist, a szál blokkolása helyett visszatér egy szálkészletbe. Ezért, amikor újabb kérés érkezik, ez az ingyenes szál újrafelhasználásra kerül. Annak ellenére, hogy a bejövő kérések száma növekszik, az alkalmazás nem igényel új szálakat, így azok száma változatlan marad.  Érdemes megemlíteni a 3. mérőszámot –   . Mindkét végpont ugyanazt az eredményt mutatta – 5200 ms. Tehát teljesítményben nincs különbség.  a medián válaszidőt  Most itt az ideje felhúzni a tétet.  2. kísérlet    : 150 felhasználók száma  Megdupláztuk a terhelést. Az aszinkron végpont sikeresen kezeli ezt a feladatot –   1500 körül mozog. A szinkron testvér végül elérte a hasonló számot, 1410-et. De ha megnézi az alábbi grafikont, látni fogja, hogy 10 percig tartott! percenkénti kérése  Ennek az az oka, hogy a szinkron végpont egy új felhasználó érkezésére egy másik szál létrehozásával reagál, de a felhasználókat gyorsabban adják hozzá a rendszerhez (csak emlékeztetve arra, hogy a   10 felhasználó/s), mint ahogy a webszerver alkalmazkodni tud. Ez az oka annak, hogy a kezdet kezdetén sok kérést állított sorba.  Spawn Rate  Nem meglepő módon a   mutatója továbbra is 34 körül van az aszinkron végpontnál, míg a szinkronnál 102-ről 155-re nőtt. A   a   sebességéhez hasonlóan csökkent – a szinkron válaszidő sokkal magasabb volt a kísérlet elején. Ha 24 órán keresztül megtartottam volna a tesztet, a medián számok párosak lettek volna.  szálszám medián válaszidő percenkénti kérés  3. kísérlet    : 200 felhasználók száma  A harmadik kísérlet célja a második során feltárt trendek bizonyítása – a szinkron végpont további romlása látható.   Következtetés  A szinkron műveletek helyett aszinkron használata nem javítja közvetlenül a teljesítményt vagy a felhasználói élményt. Először is növeli a stabilitást és a kiszámíthatóságot nyomás alatt. Más szavakkal, megemeli a terhelési küszöböt, így a rendszer többet tud feldolgozni, mielőtt leromlik.  Függelék #1. Műszaki részletek  Azure App Service: B1, 100   , 1,75 Gb memória, A sorozatú számítási megfelelője. ACU  Azure SQL Database: Standard S4: 200 DTU, 500 Mb tárhely.  SQL kapcsolat beállításai: Max Pool Size=200.  2. számú melléklet. Megjegyzések  A legtisztább teszteredmény eléréséhez teszteket kellett volna futtatnom 2 virtuális gépről, amelyek ugyanabban a hálózatban találhatók, ahol a cél App Services található.  Feltételeztem azonban, hogy a hálózati késés többé-kevésbé hasonló módon hat mindkét alkalmazásra. Ezért nem veszélyeztetheti a fő célt – az aszinkron és a szinkron módszerek viselkedésének összehasonlítását.   3. számú melléklet. Bónusz kísérlet  Mit törtem fel, hogy a szinkron végpontot majdnem ugyanolyan aszinkron működésre kényszerítsem, és ábrázoljam az alábbi grafikont (a kísérlet feltételei ugyanazok, mint a harmadiknál – 200 felhasználó)? 

Read My Stories

Buy Me a Coffee

Ez a hanganyag a történet eredeti nyelvén készült!

Async vs Sync Benchmark (.NET): Az aszinkron és a szinkron módszerek közötti különbség

About Author

HOZZÁSZÓLÁSOK

HANG TAGOK

EZT A CIKKET BEMUTATTA

Related Stories

HackerNoon Raises $250k at $50M Valuation From Forward Research

HackerNoon Contributor Denisa Ganea on HackerNoon, Human Existence, and Everything in Between

HackerNoon Social Media Presence: A Complete Guide

A SECOND ENIGMA

HackerNoon Raises $250k at $50M Valuation From Forward Research

HackerNoon Contributor Denisa Ganea on HackerNoon, Human Existence, and Everything in Between

HackerNoon Social Media Presence: A Complete Guide

A SECOND ENIGMA

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps