paint-brush
Async vs Sync Benchmark (.NET): Asinxron və Sinxron Metodlar Arasındakı Fərqtərəfindən@artemmikulich
1,873 oxunuşlar
1,873 oxunuşlar

Async vs Sync Benchmark (.NET): Asinxron və Sinxron Metodlar Arasındakı Fərq

tərəfindən Artem Mikulich5m2024/09/21
Read on Terminal Reader

Çox uzun; Oxumaq

Bu məqalə praktikada asinxron və sinxron metodlar arasındakı fərqi göstərir. İki müstəqil çəyirtkə nümunəsi iki maşında işləyir. İstifadəçilərin sayı hədəf sayına bərabər artır (*İstifadəçilərin sayı*). Artım sürəti * Spawn Rate* parametri ilə idarə olunur (saniyədə qoşulacaq unikal istifadəçilərin sayı)
featured image - Async vs Sync Benchmark (.NET): Asinxron və Sinxron Metodlar Arasındakı Fərq
Artem Mikulich HackerNoon profile picture

Ən sevdiyim müsahibə suallarından biri də “ Asinkgözləyən sözlər sizə nə deyir?”. çünki bu, müsahiblə maraqlı müzakirə aparmaq imkanı yaradır... Yaxud da bu mövzuda danışdıqları üçün yox. Fikrimcə, bu texnikadan niyə istifadə etdiyimizi başa düşmək çox vacibdir.


Mənə elə gəlir ki, bir çox tərtibatçılar “ən yaxşı təcrübədir” ifadəsinə etibar etməyi və asinxron metodlardan kor-koranə istifadə etməyi üstün tuturlar.


Bu məqalə praktikada asinxron və sinxron metodlar arasındakı fərqi göstərir.

Alətlər

  • .NET Web API tətbiqi (test hədəfi)


  • 2 Azure SQL verilənlər bazası


  • 2 Windows-da Azure Tətbiq Xidməti (tətbiqi qəbul edir)


  • Azure App Insights (metrikləri toplamaq üçün)


  • çəyirtkə çərçivəsi (istifadəçi yükünü simulyasiya etmək üçün).

Konfiqurasiya

Təcrübə sxemi

Aşağıdakı şəkildə bir benchmark işlədəcəm. İki müstəqil çəyirtkə nümunəsi iki maşında işləyir. Çəyirtkə nümunələri aşağıdakıları edən istifadəçini simulyasiya edir:

  • Çəyirtkə host 1-dən olan istifadəçi Tətbiq Xidməti 1- in sinxron son nöqtəsinə toxunur, cavab alır və 0,5-1 saniyə boş qalır (dəqiq vaxt gecikməsi təsadüfidir). Təcrübənin sonuna qədər təkrarlanır.


  • Çəyirtkə host 2-dən olan istifadəçi yalnız bir fərqlə tam olaraq eyni davranır — o, App Service 2- nin asinxron son nöqtəsinə çatır.


Başlıq altında hər bir Tətbiq Xidməti öz verilənlər bazasına qoşulur və beş saniyə çəkən və bir neçə sıra məlumatı qaytaran SELECT sorğusunu yerinə yetirir. İstinadlar üçün aşağıdakı nəzarətçi koduna baxın. Mən verilənlər bazasına zəng etmək üçün Dapper-dən istifadə edəcəyəm. Diqqətinizi ona yönəltmək istərdim ki, asinxron son nöqtə verilənlər bazasını asinxron olaraq da çağırır ( QueryAsync<T> ).


Tətbiq Xidmətləri kodu


Əlavə etmək lazımdır ki, mən eyni kodu hər iki proqram xidmətinə yerləşdirirəm.


Test zamanı istifadəçilərin sayı hədəf sayına bərabər artır ( İstifadəçilərin sayı ). Artım sürəti Spawn Rate parametri ilə idarə olunur (saniyədə qoşulacaq unikal istifadəçilərin sayı) — rəqəm nə qədər çox olarsa, istifadəçilər bir o qədər tez əlavə olunur. Kürü sürəti bütün eksperimentlər üçün 10 istifadəçi/s olaraq təyin edilib.


Bütün təcrübələr 15 dəqiqə ilə məhdudlaşır.


Maşın konfiqurasiya təfərrüatlarını məqalənin Texniki Təfərrüatlar bölməsində tapa bilərsiniz.

Metriklər

  • dəqiqədə sorğular — proqramın həqiqətən emal etdiyi və status kodunu qaytardığı sorğuların sayını göstərir.
  • mövzu sayı — proqram xidmətinin istehlak etdiyi mövzuların sayını göstərir.
  • median cavab müddəti, ms


Qırmızı xətlər uyğun olaraq asinxron, mavi xətlər isə sinxron son nöqtəyə aiddir.


Bu nəzəriyyə haqqında. başlayaq.

Təcrübə №1

  • istifadəçilərin sayı : 75 (hər xidmətə görə)


Görə bilərik ki, hər iki son nöqtə eyni şəkildə işləyir - 5200 ms median cavab müddəti ilə dəqiqədə təxminən 750 sorğunu idarə edir.


Təcrübə №1. Dəqiqədə sorğular


Bu təcrübədə ən maraqlı qrafik iplik trendidir. Sinxron son nöqtə (mavi qrafik) üçün əhəmiyyətli dərəcədə yüksək rəqəmlər görə bilərsiniz - 100-dən çox mövzu!


Təcrübə №1. Mövzu sayı


Baxmayaraq ki, bu gözləniləndir və nəzəriyyəyə uyğundur — sorğu daxil olduqda və proqram verilənlər bazasına zəng etdikdə mövzu bloklanır, çünki o, gediş-gəlişin tamamlanmasını gözləməli olur. Buna görə də, başqa bir sorğu daxil olduqda, proqram onu idarə etmək üçün yeni bir mövzu yaratmalıdır.


Qırmızı qrafik - asinxron son nöqtə mövzu sayı - fərqli davranışı sübut edir. Sorğu daxil olduqda və proqram verilənlər bazasına zəng etdikdə, mövzu bloklanmaq əvəzinə mövzu hovuzuna qayıdır. Buna görə də, başqa bir sorğu daxil olduqda, bu pulsuz mövzu yenidən istifadə olunur. Daxil olan sorğuların artmasına baxmayaraq, proqram heç bir yeni mövzu tələb etmir, ona görə də onların sayı eyni qalır.


3-cü metrik - median cavab müddətini qeyd etməyə dəyər. Hər iki son nöqtə eyni nəticəni göstərdi - 5200 ms. Deməli, performans baxımından heç bir fərq yoxdur.


Təcrübə №1. Xülasə


İndi payları qaldırmağın vaxtıdır.

Eksperiment #2

  • İstifadəçilərin sayı : 150


Yükü iki qat artırdıq. Asinxron son nöqtə bu tapşırığı uğurla yerinə yetirir – onun dəqiqəlik tələbi 1500 ətrafında dəyişir. Sinxron qardaş nəhayət, müqayisə olunan 1410 sayına çatdı. Lakin aşağıdakı qrafikə baxsanız, bunun 10 dəqiqə çəkdiyini görəcəksiniz!


Səbəb odur ki, sinxron son nöqtə yeni istifadəçinin gəlişinə başqa mövzu yaradaraq reaksiya verir, lakin istifadəçilər sistemə əlavə edilir (yalnız sizə xatırlatmaq üçün ki, Kürü Rate 10 istifadəçi/s) veb serverin uyğunlaşa bildiyindən daha tezdir. Ona görə də ilk vaxtlarda çoxlu müraciətləri növbəyə qoydu.


Təcrübə №2. Dəqiqədə sorğular


Təəccüblü deyil ki, iplərin sayı metrikası asinxron son nöqtə üçün hələ də 34-ə yaxındır, sinxron olan üçün isə 102-dən 155-ə yüksəlmişdir. Median cavab müddəti bir dəqiqəlik sorğu ilə eyni şəkildə azaldı - sinxron cavab müddəti eksperimentin əvvəlində daha yüksək idi. Testi 24 saat saxlasaydım, median rəqəmlər bərabər olardı.


Eksperiment #2. Xülasə


Eksperiment #3

  • İstifadəçilərin sayı : 200


Üçüncü eksperiment ikincisi zamanı aşkar edilmiş tendensiyaları sübut etmək üçün nəzərdə tutulub - biz sinxron son nöqtənin daha da deqradasiyasını görə bilərik.


Eksperiment #3. Xülasə


Nəticə

Sinxron əməliyyatlar yerinə asinxrondan istifadə performansı və ya istifadəçi təcrübəsini birbaşa yaxşılaşdırmır. Birincisi, təzyiq altında sabitliyi və proqnozlaşdırıla bilənliyi artırır. Başqa sözlə, o, yük həddini qaldırır ki, sistem pisləşmədən əvvəl daha çox emal edə bilsin.

Əlavə №1. Texniki Detallar

  • Azure Tətbiq Xidməti: B1, 100 ACU , 1,75 Gb Yaddaş, A-Series hesablama ekvivalenti.
  • Azure SQL verilənlər bazası: Standart S4: 200 DTU, 500 Mb yaddaş.
  • SQL Bağlantı parametrləri: Max Pool Size=200.

Əlavə №2. Qeydlər

Ən təmiz test nəticəsini əldə etmək üçün hədəf Tətbiq Xidmətlərinin yerləşdiyi eyni şəbəkədə yerləşən 2 VM-dən testlər keçirməliydim.


Bununla belə, mən güman edirdim ki, şəbəkə gecikməsi hər iki tətbiqə daha çox və ya daha az oxşar şəkildə təsir edəcək. Buna görə də, o, əsas məqsədə - asinxron və sinxron metodların necə davrandığını müqayisə etməyə təhlükə yarada bilməz.

Əlavə №3. Bonus Təcrübə

Sinxron son nöqtəni demək olar ki, asinxron işləməyə məcbur etmək və aşağıdakı qrafiki tərtib etmək üçün nəyi sındırdım (təcrübə şərtləri üçüncü ilə eynidir — 200 istifadəçi)?


Bonus Təcrübə. Dəqiqədə sorğular