paint-brush
Async vs Sync Benchmark (.NET): Асинхрондуу жана синхрондуу методдордун ортосундагы айырматарабынан@artemmikulich
1,892 окуулар
1,892 окуулар

Async vs Sync Benchmark (.NET): Асинхрондуу жана синхрондуу методдордун ортосундагы айырма

тарабынан Artem Mikulich5m2024/09/21
Read on Terminal Reader

өтө узун; Окуу

Бул макалада иш жүзүндө асинхрондук жана синхрондуу ыкмаларынын ортосундагы айырманы көрсөтөт. Эки көз карандысыз чегиртке эки станокто иштеп жатат. Колдонуучулардын саны максаттуу санга бирдей өсөт (*Колдонуучулардын саны*). Өсүү ылдамдыгы * Spawn Rate* параметри менен башкарылат (секундасына кошула турган уникалдуу колдонуучулардын саны)
featured image - Async vs Sync Benchmark (.NET): Асинхрондуу жана синхрондуу методдордун ортосундагы айырма
Artem Mikulich HackerNoon profile picture

Менин сүйүктүү интервью суроолорумдун бири: " Асинхрондук жана күтүү сыяктуу сөздөр сизге эмне дейт?" анткени бул интервьючу менен кызыктуу маек курууга мүмкүнчүлүк ачат... Же бул темада калкып жүргөндүктөн эмес. Менимче, бул ыкманы эмне үчүн колдонуп жатканыбызды түшүнүү абдан маанилүү.


Менимче, көптөгөн иштеп чыгуучулар "бул эң жакшы тажрыйба" деген сөзгө таянып, асинхрондук ыкмаларды сокур колдонууну артык көрүшөт.


Бул макалада иш жүзүндө асинхрондук жана синхрондуу ыкмаларынын ортосундагы айырманы көрсөтөт.

Куралдар

  • .NET Web API колдонмосу (сыноо максаты)


  • 2 Azure SQL маалымат базалары


  • 2 Windows боюнча Azure App Service (тиркемени жайгаштырат)


  • Azure App Insights (метрикаларды чогултуу үчүн)


  • чегиртке негизи (колдонуучунун жүгүн симуляциялоо үчүн).

Конфигурация

Эксперимент схемасы

Мен төмөнкү жол менен эталонду иштетем. Эки көз карандысыз чегиртке эки станокто иштеп жатат. Чегиртке мисалдары колдонуучуну имитациялайт, ал төмөнкүлөрдү аткарат:

  • Чегиртке хостунун 1 колдонуучусу Колдонмо кызматынын 1 синхрондуу акыркы чекитине тийип, жооп алат жана 0,5–1 секунд бош турат (так убакыт кечигүү кокустук). Эксперименттин аягына чейин кайталанат.


  • Чегиртке 2 хостунун колдонуучусу өзүн бирдей алып жүрөт, бир гана айырмасы бар — ал App Service 2нин асинхрондуу акыркы чекитине тийет.


Капчыктын астында ар бир Колдонмо кызматы өзүнүн маалымат базасына туташып, беш секундга созулган SELECT суроосун аткарат жана бир нече катар маалыматтарды кайтарат. Шилтемелер үчүн төмөнкү контроллердин кодун караңыз. Мен маалымат базасына чалуу үчүн Dapper колдоном. Мен сиздин көңүлүңүздү асинхрондуу акыркы чекит маалымат базасын асинхрондук түрдө чакырганына бургум келет ( QueryAsync<T> ).


Колдонмо кызматтарынын коду


Кошумчалай кетүүчү нерсе, мен бир эле кодду эки колдонмо кызматына тең колдоном.


Сыноо учурунда колдонуучулардын саны максаттуу санга бирдей өсөт ( Колдонуучулардын саны ). Өсүү ылдамдыгы Spawn Rate параметри (секундасына кошула турган уникалдуу колдонуучулардын саны) менен көзөмөлдөнөт — бул сан канчалык көп болсо, колдонуучулар ошончолук тезирээк кошулат. Бардык эксперименттер үчүн урук тартуу ылдамдыгы 10 колдонуучу/сек деп коюлган.


Бардык эксперименттер 15 мүнөт менен чектелген.


Машинанын конфигурациясынын чоо-жайын макаланын Техникалык деталдары бөлүмүнөн таба аласыз.

Metrics

  • мүнөтүнө суроо-талаптар — колдонмо иш жүзүндө иштеп чыккан жана статус кодун кайтарган сурамдардын санын көрсөтөт.
  • жип саны — колдонмо кызматы керектеген жиптердин санын көрсөтөт.
  • медианалык жооп убактысы, мс


Кызыл сызыктар асинхрондук, ал эми көк сызыктар синхрондуу акыркы чекитке тиешелүү.


Бул теория жөнүндө. баштайлы.

Эксперимент №1

  • колдонуучулардын саны : 75 (бир кызмат үчүн)


Биз эки акыркы чекиттин бирдей иштешин көрө алабыз - 5200 мс медианалык жооп берүү убактысы менен мүнөтүнө болжол менен 750 суроону аткарат.


Эксперимент №1. Мүнөтүнө суроо-талаптар


Бул эксперименттеги эң кызыктуу график жип тренди болуп саналат. Сиз синхрондуу акыркы чекит үчүн кыйла жогору сандарды көрө аласыз (көк график) — 100дөн ашык жиптер!


Эксперимент №1. Жип саны


Бул күтүлгөн жана теорияга дал келет — өтүнүч келип түшкөндө жана колдонмо маалымат базасына чалуу жасаганда, жип бөгөттөлөт, анткени ал айланып чыгууну күтүшү керек. Ошондуктан, башка суроо келгенде, колдонмо аны иштетүү үчүн жаңы жипти чыгарышы керек.


Кызыл график - асинхрондук акыркы чекит жиптеринин саны - ар кандай жүрүм-турумду далилдейт. Сурам келип түшкөндө жана колдонмо маалымат базасына чалуу жасаганда, жип бөгөттөлгөндүн ордуна жип бассейнине кайтып келет. Ошондуктан, башка өтүнүч келгенде, бул бекер жип кайра колдонулат. Кирүүчү суроо-талаптар өсүп жатканына карабастан, колдонмо эч кандай жаңы жиптерди талап кылбайт, андыктан алардын саны өзгөрүүсүз калат.


Үчүнчү метриканы белгилей кетүү керек — жооп берүү убактысынын медианасы . Эки акыркы чекит бирдей жыйынтыкты көрсөттү — 5200 мс. Демек, аткаруу жагынан эч кандай айырма жок.


Эксперимент №1. Жыйынтык


Эми, бул коюмдарды көтөрүүгө убакыт жетти.

Эксперимент №2

  • колдонуучулардын саны : 150


Биз жүктү эки эсеге көтөрдүк. Асинхрондук акыркы чекит бул тапшырманы ийгиликтүү аткарат — анын суроо-талабы мүнөтүнө 1500дүн тегерегинде калкып чыгат. Синхрондуу бир тууган акыры салыштырмалуу 1410 санга жетти. Бирок төмөндөгү графикти карасаңыз, ага 10 мүнөт кеткенин көрөсүз!


Себеби, синхрондуу акыркы чекит жаңы колдонуучунун келишине башка жипти түзүү менен жооп берет, бирок колдонуучулар системага кошулуп жатышат (жөн гана сизге Spawn Rate 10 колдонуучу/с экенин эскертиш үчүн) веб-сервер ыңгайлаша алгандан тезирээк. Ошон үчүн эң башында эле көп суроо-талаптарды кезекке тургузган.


Эксперимент №2. Мүнөтүнө суроо-талаптар


Таң калыштуусу, жиптердин санынын көрсөткүчү асинхрондук акыркы чекит үчүн дагы эле 34түн тегерегинде, ал эми синхрондук үчүн 102ден 155ке чейин өстү. Медианалык жооп берүү убактысы мүнөтүнө суроо- талапка окшош эле начарлады - синхрондуу жооп берүү убактысы эксперименттин башында бир топ жогору болгон. Эгерде мен тестти 24 саат бою кармасам, медианалык сандар жуп болуп калмак.


Эксперимент №2. Жыйынтык


Эксперимент №3

  • колдонуучулардын саны : 200


Үчүнчү эксперимент экинчисинде ачылган тенденцияларды далилдөөгө арналган — биз синхрондуу акыркы чекиттин андан ары деградациясын көрө алабыз.


Эксперимент №3. Жыйынтык


Корутунду

Синхрондуу операциялардын ордуна асинхрондук колдонуу натыйжалуулукту же колдонуучунун тажрыйбасын түздөн-түз жакшыртпайт. Биринчиден, ал басым астында туруктуулукту жана алдын ала айтууну күчөтөт. Башка сөз менен айтканда, ал жүк босогосун жогорулатат, андыктан система бузулганга чейин көбүрөөк иштете алат.

№1 тиркеме. Техникалык маалыматтар

  • Azure App Service: B1, 100 ACU , 1,75 Гб эстутум, A-Series эсептөө эквиваленти.
  • Azure SQL базасы: Стандарттык S4: 200 DTU, 500 Мб сактагыч.
  • SQL туташуу орнотуулары: Макс Пул көлөмү = 200.

№2 тиркеме. Эскертүүлөр

Сыноонун эң таза натыйжасына жетүү үчүн, мен максаттуу Колдонмо кызматтары отурган тармакта жайгашкан 2 VMден тесттерди өткөрүшүм керек болчу.


Бирок, мен тармактын артта калуусу эки колдонмого тең аздыр-көптүр таасир этет деп ойлогом. Ошондуктан, ал негизги максатты - асинхрондук жана синхрондук ыкмаларды кандайча алып жүрөрүн салыштыра албайт.

№3 тиркеме. Bonus Experiment

Синхрондуу акыркы чекитти дээрлик асинхрондук кылып, төмөндөгү графикти түзүүгө мажбурлоо үчүн мен эмнени бузуп алдым (эксперимент шарттары үчүнчүдөгүдөй — 200 колдонуучу)?


Bonus Experiment. Мүнөтүнө суроо-талаптар


L O A D I N G
. . . comments & more!

About Author

Artem Mikulich HackerNoon profile picture
Artem Mikulich@artemmikulich
Solutions Architect, Azure cloud expert, blogger, trainer, professional racing driver.

ТАГИП АЛУУ

БУЛ МАКАЛА БЕРИЛГЕН...