Async vs Sync Benchmark (.NET)៖ ភាពខុសគ្នារវាងវិធីសាស្ត្រ Asynchronous និង Synchronous Methods

សំណួរសំភាសន៍ដែលខ្ញុំចូលចិត្តបំផុតមួយគឺ "តើពាក្យដែល ធ្វើសមកាលកម្ម ហើយ រង់ចាំ ប្រាប់អ្នកអំពីអ្វី?" ព្រោះវាបើកឱកាសឱ្យមានការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍ជាមួយអ្នកសម្ភាសន៍... ឬវាមិនមែនដោយសារតែពួកគេអណ្តែតលើប្រធានបទនេះ។ តាមគំនិតរបស់ខ្ញុំ វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការយល់ពីមូលហេតុដែលយើងប្រើបច្ចេកទេសនេះ។

ខ្ញុំមានអារម្មណ៍ថាអ្នកអភិវឌ្ឍន៍ជាច្រើនចូលចិត្តពឹងផ្អែកលើសេចក្តីថ្លែងការណ៍ "វាគឺជាការអនុវត្តល្អបំផុត" ហើយប្រើវិធីសាស្ត្រអសមកាលដោយងងឹតងងល់។

អត្ថបទនេះបង្ហាញពីភាពខុសគ្នារវាងវិធីសាស្ត្រអសមកាល និងសមកាលកម្មក្នុងការអនុវត្ត។

ឧបករណ៍

• កម្មវិធី .NET Web API (គោលដៅសាកល្បង)

• 2 មូលដ្ឋានទិន្នន័យ Azure SQL

• 2 Azure App Service នៅលើ Windows (រៀបចំកម្មវិធី)

• Azure App Insights (ដើម្បីប្រមូលរង្វាស់)

• ក្របខណ្ឌ កណ្ដូប (ដើម្បីក្លែងធ្វើបន្ទុកអ្នកប្រើប្រាស់)។

ការកំណត់រចនាសម្ព័ន្ធ

ខ្ញុំនឹងដំណើរការតារាងពិន្ទុតាមវិធីខាងក្រោម។ ករណីកណ្តូបឯករាជ្យពីរកំពុងដំណើរការលើម៉ាស៊ីនពីរ។ Locust instances ក្លែងធ្វើអ្នកប្រើប្រាស់ដែលធ្វើដូចខាងក្រោម៖

• អ្នកប្រើប្រាស់មកពីម៉ាស៊ីនកណ្ដូប 1 ប៉ះចំណុចបញ្ចប់ សមកាលកម្ម នៃ សេវាកម្មកម្មវិធី 1 ទទួលបានការឆ្លើយតប និងនៅទំនេររយៈពេល 0.5-1 វិនាទី (ការពន្យារពេលពេលវេលាពិតប្រាកដគឺចៃដន្យ)។ ធ្វើម្តងទៀតរហូតដល់ចុងបញ្ចប់នៃការពិសោធន៍។

• អ្នកប្រើប្រាស់មកពីម៉ាស៊ីនកណ្ដូប 2 មានឥរិយាបថដូចគ្នាយ៉ាងជាក់លាក់ ដោយមានភាពខុសគ្នាតែមួយប៉ុណ្ណោះ គឺគាត់បានទៅដល់ចំណុចបញ្ចប់ អសមកាល នៃ សេវាកម្មកម្មវិធី 2 ។

នៅក្រោមក្រណាត់ សេវាកម្មកម្មវិធីនីមួយៗភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួនរបស់វា ហើយដំណើរការសំណួរ SELECT ដែលចំណាយពេលប្រាំវិនាទី ហើយត្រឡប់ទិន្នន័យពីរបីជួរ។ សូមមើលកូដរបស់ឧបករណ៍បញ្ជាខាងក្រោមសម្រាប់ឯកសារយោង។ ខ្ញុំនឹងប្រើ Dapper ដើម្បីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ។ ខ្ញុំ​ចង់​ទាញ​យក​ចិត្ត​ទុក​ដាក់​របស់​អ្នក​ចំពោះ​ការ​ពិត​ដែល​ចំណុច​ចុង​អសមកាល​ហៅ​មូលដ្ឋាន​ទិន្នន័យ​អសមកាល​ផង​ដែរ ( QueryAsync<T> )។

វាមានតម្លៃបន្ថែមថាខ្ញុំដាក់កូដដូចគ្នាទៅនឹងសេវាកម្មកម្មវិធីទាំងពីរ។

កំឡុងពេលធ្វើតេស្ត ចំនួនអ្នកប្រើប្រាស់កើនឡើងស្មើៗគ្នាទៅនឹងចំនួនគោលដៅ ( ចំនួនអ្នកប្រើប្រាស់ )។ ល្បឿននៃកំណើនត្រូវបានគ្រប់គ្រងដោយប៉ារ៉ាម៉ែត្រ អត្រា Spawn (ចំនួនអ្នកប្រើប្រាស់តែមួយគត់ដើម្បីចូលរួមក្នុងមួយវិនាទី) — ចំនួនកាន់តែខ្ពស់ អ្នកប្រើប្រាស់កាន់តែលឿនត្រូវបានបន្ថែម។ អត្រាពង ត្រូវបានកំណត់ទៅ 10 អ្នកប្រើប្រាស់/s សម្រាប់ការពិសោធន៍ទាំងអស់។

ការពិសោធន៍ទាំងអស់ត្រូវបានកំណត់ត្រឹម 15 នាទី។

អ្នកអាចស្វែងរកព័ត៌មានលម្អិតអំពីការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីននៅក្នុងផ្នែកព័ត៌មានលម្អិតបច្ចេកទេសនៃអត្ថបទ។

ម៉ែត្រ

• សំណើក្នុងមួយនាទី — បង្ហាញចំនួនសំណើដែលកម្មវិធីពិតជាបានដំណើរការ និងត្រឡប់លេខកូដស្ថានភាព។
• ចំនួនខ្សែស្រឡាយ — បង្ហាញចំនួនខ្សែស្រឡាយដែលសេវាកម្មកម្មវិធីប្រើប្រាស់។
• ពេលវេលាឆ្លើយតបជាមធ្យម, ms

បន្ទាត់ក្រហមសំដៅទៅលើអសមកាល និងបន្ទាត់ពណ៌ខៀវ — ទៅកាន់ចំណុចបញ្ចប់សមកាលកម្មរៀងគ្នា។

នោះហើយជាវាអំពីទ្រឹស្តី។ តោះចាប់ផ្តើម។

ការពិសោធន៍លេខ 1

• ចំនួនអ្នកប្រើប្រាស់ ៖ ៧៥នាក់ (ក្នុងមួយសេវាកម្ម)

យើងអាចមើលឃើញថាចំណុចបញ្ចប់ទាំងពីរដំណើរការស្រដៀងគ្នា — ដោះស្រាយសំណើប្រហែល 750 ក្នុងមួយនាទីជាមួយនឹងពេលវេលាឆ្លើយតបជាមធ្យម 5200 ms ។

ក្រាហ្វដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនៅក្នុងការពិសោធន៍នេះគឺជានិន្នាការខ្សែស្រឡាយ។ អ្នក​អាច​មើល​ឃើញ​លេខ​ដែល​ខ្ពស់​ជាង​នេះ​សម្រាប់​ចំណុច​បញ្ចប់​សមកាលកម្ម (ក្រាហ្វ​ពណ៌​ខៀវ) — ជាង 100 ខ្សែ!

នោះជាការរំពឹងទុក និងត្រូវគ្នានឹងទ្រឹស្តី — នៅពេលដែលសំណើមួយចូលមក ហើយកម្មវិធីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ ខ្សែស្រលាយត្រូវបានរារាំង ព្រោះវាត្រូវរង់ចាំការធ្វើដំណើរជុំគ្នាដើម្បីបញ្ចប់។ ដូច្នេះនៅពេលដែលសំណើមួយផ្សេងទៀតចូលមក កម្មវិធីត្រូវតែបង្កើតខ្សែថ្មីដើម្បីដោះស្រាយវា។

ក្រាហ្វក្រហម - ចំនួនខ្សែស្រឡាយចុងអសមកាល - បង្ហាញពីអាកប្បកិរិយាខុសគ្នា។ នៅពេលដែលសំណើចូលមក ហើយកម្មវិធីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ ខ្សែស្រឡាយត្រឡប់ទៅក្រុមខ្សែស្រឡាយ ជំនួសឱ្យការត្រូវបានរារាំង។ ដូច្នេះនៅពេលដែលសំណើមួយផ្សេងទៀតចូលមក ខ្សែស្រលាយឥតគិតថ្លៃនេះត្រូវបានប្រើឡើងវិញ។ ទោះបីជាមានសំណើចូលកើនឡើងក៏ដោយ ក៏កម្មវិធីមិនទាមទារខ្សែថ្មីទេ ដូច្នេះចំនួនរបស់ពួកគេនៅតែដដែល។

វាមានតម្លៃនិយាយអំពីម៉ែត្រទី 3 — ពេលវេលាឆ្លើយតបជាមធ្យម ។ ចំណុចបញ្ចប់ទាំងពីរបានបង្ហាញលទ្ធផលដូចគ្នា — 5200 ms ។ ដូច្នេះ​មិន​មាន​អ្វី​ខុស​គ្នា​ក្នុង​លក្ខខណ្ឌ​នៃ​ការ​អនុវត្ត។

ឥឡូវនេះ វាដល់ពេលហើយដើម្បីទាញភាគហ៊ុន។

ការពិសោធន៍ # 2

• ចំនួនអ្នកប្រើប្រាស់ ៖ ១៥០

យើងបង្កើនបន្ទុកទ្វេដង។ ចំណុចបញ្ចប់អសមកាលគ្រប់គ្រងកិច្ចការនេះដោយជោគជ័យ — អត្រា សំណើក្នុងមួយនាទី របស់វាអណ្តែតនៅជុំវិញ 1500 ។ បងប្អូនដែលធ្វើសមកាលកម្មនៅទីបំផុតបានឈានដល់ចំនួនប្រៀបធៀបនៃ 1410 ។ ប៉ុន្តែប្រសិនបើអ្នកក្រឡេកមើលក្រាហ្វខាងក្រោម អ្នកនឹងឃើញថាវាចំណាយពេល 10 នាទី!

ហេតុផលគឺថាចំនុចបញ្ចប់សមកាលកម្មមានប្រតិកម្មចំពោះការមកដល់របស់អ្នកប្រើថ្មីដោយបង្កើតខ្សែស្រឡាយផ្សេងទៀត ប៉ុន្តែអ្នកប្រើប្រាស់កំពុងត្រូវបានបញ្ចូលទៅក្នុងប្រព័ន្ធ (គ្រាន់តែដើម្បីរំលឹកអ្នកថា អត្រា Spawn គឺ 10 អ្នកប្រើប្រាស់/s) លឿនជាងម៉ាស៊ីនមេគេហទំព័រអាចសម្របបាន។ នោះហើយជាមូលហេតុដែលវាតម្រង់ជួរសំណើជាច្រើននៅដើមដំបូង។

មិនគួរឱ្យភ្ញាក់ផ្អើលទេ មាត្រដ្ឋាន រាប់ខ្សែស្រឡាយ នៅតែមានប្រហែល 34 សម្រាប់ចំណុចបញ្ចប់អសមកាល ខណៈពេលដែលវាកើនឡើងពី 102 ទៅ 155 សម្រាប់សមកាលកម្មមួយ។ ពេលវេលាឆ្លើយតបជាមធ្យម បានបន្ទាបបន្ថោកស្រដៀងគ្នាទៅនឹងអត្រា សំណើក្នុងមួយនាទី — ពេលវេលាឆ្លើយតបសមកាលកម្មគឺខ្ពស់ជាងនៅដើមដំបូងនៃការពិសោធន៍។ ប្រសិនបើខ្ញុំបានរក្សាការធ្វើតេស្តរយៈពេល 24 ម៉ោង នោះលេខមធ្យមនឹងក្លាយទៅជាគូ។

ការពិសោធន៍លេខ ៣

• ចំនួនអ្នកប្រើប្រាស់ ៖ ២០០នាក់។

ការពិសោធន៍ទីបីគឺមានបំណងដើម្បីបញ្ជាក់អំពីនិន្នាការដែលបានបង្ហាញក្នុងអំឡុងពេលទីពីរ — យើងអាចមើលឃើញការរិចរិលបន្ថែមទៀតនៃចំណុចបញ្ចប់សមកាលកម្ម។

សេចក្តីសន្និដ្ឋាន

ការប្រើអសមកាលជំនួសឱ្យប្រតិបត្តិការសមកាលកម្មមិនធ្វើអោយប្រសើរឡើងនូវការអនុវត្ត ឬបទពិសោធន៍អ្នកប្រើប្រាស់ដោយផ្ទាល់ទេ។ ទីមួយ វាបង្កើនស្ថេរភាព និងការព្យាករណ៍នៅក្រោមសម្ពាធ។ ម្យ៉ាងវិញទៀត វាបង្កើនកម្រិតផ្ទុក ដូច្នេះប្រព័ន្ធអាចដំណើរការបន្ថែមទៀត មុនពេលដែលវាធ្លាក់ចុះ។

ឧបសម្ព័ន្ធទី ១ ។ ព័ត៌មានលម្អិតបច្ចេកទេស

• សេវាកម្មកម្មវិធី Azure៖ B1, 100 ACU , អង្គចងចាំ 1,75 Gb, សមមូលគណនាស៊េរី A។
• មូលដ្ឋានទិន្នន័យ Azure SQL: ស្តង់ដារ S4: 200 DTUs, ការផ្ទុក 500 Mb ។
• ការកំណត់ការតភ្ជាប់ SQL៖ ទំហំអាងអតិបរមា=200។

ឧបសម្ព័ន្ធទី ២ ។ កំណត់ចំណាំ

ដើម្បីសម្រេចបានលទ្ធផលតេស្តស្អាតបំផុត ខ្ញុំគួរតែដំណើរការតេស្តពី VMs ចំនួន 2 ដែលមានទីតាំងនៅក្នុងបណ្តាញតែមួយដែលសេវាកម្មកម្មវិធីគោលដៅអង្គុយ។

ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំបានសន្មត់ថាភាពយឺតយ៉ាវនៃបណ្តាញនឹងប៉ះពាល់ដល់កម្មវិធីទាំងពីរតាមរបៀបស្រដៀងគ្នាច្រើនឬតិច។ ដូច្នេះហើយ វាមិនអាចធ្វើឱ្យប៉ះពាល់ដល់គោលដៅចម្បងនោះទេ ដោយប្រៀបធៀបពីរបៀបដែលវិធីសាស្ត្រអសមកាល និងសមកាលកម្មមានឥរិយាបទ។

ឧបសម្ព័ន្ធទី ៣ ។ ការពិសោធន៍ប្រាក់រង្វាន់

តើ​ខ្ញុំ​បាន​ hack អ្វី​ដើម្បី​បង្ខំ​ឱ្យ​ចំណុច​ចុង​ធ្វើ​សមកាលកម្ម​ធ្វើ​ស្ទើរតែ​ដូច​ជា​អសមកាល​ ហើយ​គ្រោង​ក្រាហ្វ​ខាងក្រោម (លក្ខខណ្ឌ​នៃ​ការ​សាកល្បង​គឺ​ដូច​គ្នា​នឹង​ចំណុច​ទី​បី​ដែរ — 200 អ្នក​ប្រើ)?