សំណួរសំភាសន៍ដែលខ្ញុំចូលចិត្តបំផុតមួយគឺ "តើពាក្យដែល   ហើយ   ប្រាប់អ្នកអំពីអ្វី?" ព្រោះវាបើកឱកាសឱ្យមានការពិភាក្សាគួរឱ្យចាប់អារម្មណ៍ជាមួយអ្នកសម្ភាសន៍... ឬវាមិនមែនដោយសារតែពួកគេអណ្តែតលើប្រធានបទនេះ។ តាមគំនិតរបស់ខ្ញុំ វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការយល់ពីមូលហេតុដែលយើងប្រើបច្ចេកទេសនេះ។ ធ្វើសមកាលកម្ម រង់ចាំ  ខ្ញុំមានអារម្មណ៍ថាអ្នកអភិវឌ្ឍន៍ជាច្រើនចូលចិត្តពឹងផ្អែកលើសេចក្តីថ្លែងការណ៍ "វាគឺជាការអនុវត្តល្អបំផុត" ហើយប្រើវិធីសាស្ត្រអសមកាលដោយងងឹតងងល់។  អត្ថបទនេះបង្ហាញពីភាពខុសគ្នារវាងវិធីសាស្ត្រអសមកាល និងសមកាលកម្មក្នុងការអនុវត្ត។  ឧបករណ៍  កម្មវិធី .NET Web API (គោលដៅសាកល្បង)  2 មូលដ្ឋានទិន្នន័យ Azure SQL  2 Azure App Service នៅលើ Windows (រៀបចំកម្មវិធី)  Azure App Insights (ដើម្បីប្រមូលរង្វាស់)  ក្របខណ្ឌ   (ដើម្បីក្លែងធ្វើបន្ទុកអ្នកប្រើប្រាស់)។ កណ្ដូប  ការកំណត់រចនាសម្ព័ន្ធ   ខ្ញុំនឹងដំណើរការតារាងពិន្ទុតាមវិធីខាងក្រោម។ ករណីកណ្តូបឯករាជ្យពីរកំពុងដំណើរការលើម៉ាស៊ីនពីរ។ Locust instances ក្លែងធ្វើអ្នកប្រើប្រាស់ដែលធ្វើដូចខាងក្រោម៖  អ្នកប្រើប្រាស់មកពីម៉ាស៊ីនកណ្ដូប 1 ប៉ះចំណុចបញ្ចប់   នៃ   ទទួលបានការឆ្លើយតប និងនៅទំនេររយៈពេល 0.5-1 វិនាទី (ការពន្យារពេលពេលវេលាពិតប្រាកដគឺចៃដន្យ)។ ធ្វើម្តងទៀតរហូតដល់ចុងបញ្ចប់នៃការពិសោធន៍។ សមកាលកម្ម សេវាកម្មកម្មវិធី 1  អ្នកប្រើប្រាស់មកពីម៉ាស៊ីនកណ្ដូប 2 មានឥរិយាបថដូចគ្នាយ៉ាងជាក់លាក់ ដោយមានភាពខុសគ្នាតែមួយប៉ុណ្ណោះ គឺគាត់បានទៅដល់ចំណុចបញ្ចប់   នៃ  អសមកាល សេវាកម្មកម្មវិធី 2 ។  នៅក្រោមក្រណាត់ សេវាកម្មកម្មវិធីនីមួយៗភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួនរបស់វា ហើយដំណើរការសំណួរ SELECT ដែលចំណាយពេលប្រាំវិនាទី ហើយត្រឡប់ទិន្នន័យពីរបីជួរ។ សូមមើលកូដរបស់ឧបករណ៍បញ្ជាខាងក្រោមសម្រាប់ឯកសារយោង។ ខ្ញុំនឹងប្រើ Dapper ដើម្បីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ។ ខ្ញុំ​ចង់​ទាញ​យក​ចិត្ត​ទុក​ដាក់​របស់​អ្នក​ចំពោះ​ការ​ពិត​ដែល​ចំណុច​ចុង​អសមកាល​ហៅ​មូលដ្ឋាន​ទិន្នន័យ​អសមកាល​ផង​ដែរ (   )។  QueryAsync<T>  វាមានតម្លៃបន្ថែមថាខ្ញុំដាក់កូដដូចគ្នាទៅនឹងសេវាកម្មកម្មវិធីទាំងពីរ។  កំឡុងពេលធ្វើតេស្ត ចំនួនអ្នកប្រើប្រាស់កើនឡើងស្មើៗគ្នាទៅនឹងចំនួនគោលដៅ (   )។ ល្បឿននៃកំណើនត្រូវបានគ្រប់គ្រងដោយប៉ារ៉ាម៉ែត្រ   (ចំនួនអ្នកប្រើប្រាស់តែមួយគត់ដើម្បីចូលរួមក្នុងមួយវិនាទី) — ចំនួនកាន់តែខ្ពស់ អ្នកប្រើប្រាស់កាន់តែលឿនត្រូវបានបន្ថែម។   ត្រូវបានកំណត់ទៅ 10 អ្នកប្រើប្រាស់/s សម្រាប់ការពិសោធន៍ទាំងអស់។ ចំនួនអ្នកប្រើប្រាស់ អត្រា Spawn អត្រាពង  ការពិសោធន៍ទាំងអស់ត្រូវបានកំណត់ត្រឹម 15 នាទី។  អ្នកអាចស្វែងរកព័ត៌មានលម្អិតអំពីការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីននៅក្នុងផ្នែកព័ត៌មានលម្អិតបច្ចេកទេសនៃអត្ថបទ។  ម៉ែត្រ    — បង្ហាញចំនួនសំណើដែលកម្មវិធីពិតជាបានដំណើរការ និងត្រឡប់លេខកូដស្ថានភាព។ សំណើក្នុងមួយនាទី    — បង្ហាញចំនួនខ្សែស្រឡាយដែលសេវាកម្មកម្មវិធីប្រើប្រាស់។ ចំនួនខ្សែស្រឡាយ   ពេលវេលាឆ្លើយតបជាមធ្យម, ms  បន្ទាត់ក្រហមសំដៅទៅលើអសមកាល និងបន្ទាត់ពណ៌ខៀវ — ទៅកាន់ចំណុចបញ្ចប់សមកាលកម្មរៀងគ្នា។  នោះហើយជាវាអំពីទ្រឹស្តី។ តោះចាប់ផ្តើម។   ការពិសោធន៍លេខ 1    ៖ ៧៥នាក់ (ក្នុងមួយសេវាកម្ម) ចំនួនអ្នកប្រើប្រាស់  យើងអាចមើលឃើញថាចំណុចបញ្ចប់ទាំងពីរដំណើរការស្រដៀងគ្នា — ដោះស្រាយសំណើប្រហែល 750 ក្នុងមួយនាទីជាមួយនឹងពេលវេលាឆ្លើយតបជាមធ្យម 5200 ms ។   ក្រាហ្វដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនៅក្នុងការពិសោធន៍នេះគឺជានិន្នាការខ្សែស្រឡាយ។ អ្នក​អាច​មើល​ឃើញ​លេខ​ដែល​ខ្ពស់​ជាង​នេះ​សម្រាប់​ចំណុច​បញ្ចប់​សមកាលកម្ម (ក្រាហ្វ​ពណ៌​ខៀវ) — ជាង 100 ខ្សែ!   នោះជាការរំពឹងទុក និងត្រូវគ្នានឹងទ្រឹស្តី — នៅពេលដែលសំណើមួយចូលមក ហើយកម្មវិធីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ ខ្សែស្រលាយត្រូវបានរារាំង ព្រោះវាត្រូវរង់ចាំការធ្វើដំណើរជុំគ្នាដើម្បីបញ្ចប់។ ដូច្នេះនៅពេលដែលសំណើមួយផ្សេងទៀតចូលមក កម្មវិធីត្រូវតែបង្កើតខ្សែថ្មីដើម្បីដោះស្រាយវា។  ក្រាហ្វក្រហម - ចំនួនខ្សែស្រឡាយចុងអសមកាល - បង្ហាញពីអាកប្បកិរិយាខុសគ្នា។ នៅពេលដែលសំណើចូលមក ហើយកម្មវិធីធ្វើការហៅទៅកាន់មូលដ្ឋានទិន្នន័យ ខ្សែស្រឡាយត្រឡប់ទៅក្រុមខ្សែស្រឡាយ ជំនួសឱ្យការត្រូវបានរារាំង។ ដូច្នេះនៅពេលដែលសំណើមួយផ្សេងទៀតចូលមក ខ្សែស្រលាយឥតគិតថ្លៃនេះត្រូវបានប្រើឡើងវិញ។ ទោះបីជាមានសំណើចូលកើនឡើងក៏ដោយ ក៏កម្មវិធីមិនទាមទារខ្សែថ្មីទេ ដូច្នេះចំនួនរបស់ពួកគេនៅតែដដែល។  វាមានតម្លៃនិយាយអំពីម៉ែត្រទី 3 —   ។ ចំណុចបញ្ចប់ទាំងពីរបានបង្ហាញលទ្ធផលដូចគ្នា — 5200 ms ។ ដូច្នេះ​មិន​មាន​អ្វី​ខុស​គ្នា​ក្នុង​លក្ខខណ្ឌ​នៃ​ការ​អនុវត្ត។  ពេលវេលាឆ្លើយតបជាមធ្យម  ឥឡូវនេះ វាដល់ពេលហើយដើម្បីទាញភាគហ៊ុន។  ការពិសោធន៍ # 2    ៖ ១៥០ ចំនួនអ្នកប្រើប្រាស់  យើងបង្កើនបន្ទុកទ្វេដង។ ចំណុចបញ្ចប់អសមកាលគ្រប់គ្រងកិច្ចការនេះដោយជោគជ័យ — អត្រា   របស់វាអណ្តែតនៅជុំវិញ 1500 ។ បងប្អូនដែលធ្វើសមកាលកម្មនៅទីបំផុតបានឈានដល់ចំនួនប្រៀបធៀបនៃ 1410 ។ ប៉ុន្តែប្រសិនបើអ្នកក្រឡេកមើលក្រាហ្វខាងក្រោម អ្នកនឹងឃើញថាវាចំណាយពេល 10 នាទី! សំណើក្នុងមួយនាទី  ហេតុផលគឺថាចំនុចបញ្ចប់សមកាលកម្មមានប្រតិកម្មចំពោះការមកដល់របស់អ្នកប្រើថ្មីដោយបង្កើតខ្សែស្រឡាយផ្សេងទៀត ប៉ុន្តែអ្នកប្រើប្រាស់កំពុងត្រូវបានបញ្ចូលទៅក្នុងប្រព័ន្ធ (គ្រាន់តែដើម្បីរំលឹកអ្នកថា   គឺ 10 អ្នកប្រើប្រាស់/s) លឿនជាងម៉ាស៊ីនមេគេហទំព័រអាចសម្របបាន។ នោះហើយជាមូលហេតុដែលវាតម្រង់ជួរសំណើជាច្រើននៅដើមដំបូង។  អត្រា Spawn  មិនគួរឱ្យភ្ញាក់ផ្អើលទេ មាត្រដ្ឋាន   នៅតែមានប្រហែល 34 សម្រាប់ចំណុចបញ្ចប់អសមកាល ខណៈពេលដែលវាកើនឡើងពី 102 ទៅ 155 សម្រាប់សមកាលកម្មមួយ។   បានបន្ទាបបន្ថោកស្រដៀងគ្នាទៅនឹងអត្រា   — ពេលវេលាឆ្លើយតបសមកាលកម្មគឺខ្ពស់ជាងនៅដើមដំបូងនៃការពិសោធន៍។ ប្រសិនបើខ្ញុំបានរក្សាការធ្វើតេស្តរយៈពេល 24 ម៉ោង នោះលេខមធ្យមនឹងក្លាយទៅជាគូ។  រាប់ខ្សែស្រឡាយ ពេលវេលាឆ្លើយតបជាមធ្យម សំណើក្នុងមួយនាទី  ការពិសោធន៍លេខ ៣    ៖ ២០០នាក់។ ចំនួនអ្នកប្រើប្រាស់  ការពិសោធន៍ទីបីគឺមានបំណងដើម្បីបញ្ជាក់អំពីនិន្នាការដែលបានបង្ហាញក្នុងអំឡុងពេលទីពីរ — យើងអាចមើលឃើញការរិចរិលបន្ថែមទៀតនៃចំណុចបញ្ចប់សមកាលកម្ម។   សេចក្តីសន្និដ្ឋាន  ការប្រើអសមកាលជំនួសឱ្យប្រតិបត្តិការសមកាលកម្មមិនធ្វើអោយប្រសើរឡើងនូវការអនុវត្ត ឬបទពិសោធន៍អ្នកប្រើប្រាស់ដោយផ្ទាល់ទេ។ ទីមួយ វាបង្កើនស្ថេរភាព និងការព្យាករណ៍នៅក្រោមសម្ពាធ។ ម្យ៉ាងវិញទៀត វាបង្កើនកម្រិតផ្ទុក ដូច្នេះប្រព័ន្ធអាចដំណើរការបន្ថែមទៀត មុនពេលដែលវាធ្លាក់ចុះ។  ឧបសម្ព័ន្ធទី ១ ។ ព័ត៌មានលម្អិតបច្ចេកទេស  សេវាកម្មកម្មវិធី Azure៖ B1, 100   , អង្គចងចាំ 1,75 Gb, សមមូលគណនាស៊េរី A។ ACU  មូលដ្ឋានទិន្នន័យ Azure SQL: ស្តង់ដារ S4: 200 DTUs, ការផ្ទុក 500 Mb ។  ការកំណត់ការតភ្ជាប់ SQL៖ ទំហំអាងអតិបរមា=200។  ឧបសម្ព័ន្ធទី ២ ។ កំណត់ចំណាំ  ដើម្បីសម្រេចបានលទ្ធផលតេស្តស្អាតបំផុត ខ្ញុំគួរតែដំណើរការតេស្តពី VMs ចំនួន 2 ដែលមានទីតាំងនៅក្នុងបណ្តាញតែមួយដែលសេវាកម្មកម្មវិធីគោលដៅអង្គុយ។  ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំបានសន្មត់ថាភាពយឺតយ៉ាវនៃបណ្តាញនឹងប៉ះពាល់ដល់កម្មវិធីទាំងពីរតាមរបៀបស្រដៀងគ្នាច្រើនឬតិច។ ដូច្នេះហើយ វាមិនអាចធ្វើឱ្យប៉ះពាល់ដល់គោលដៅចម្បងនោះទេ ដោយប្រៀបធៀបពីរបៀបដែលវិធីសាស្ត្រអសមកាល និងសមកាលកម្មមានឥរិយាបទ។   ឧបសម្ព័ន្ធទី ៣ ។ ការពិសោធន៍ប្រាក់រង្វាន់  តើ​ខ្ញុំ​បាន​ hack អ្វី​ដើម្បី​បង្ខំ​ឱ្យ​ចំណុច​ចុង​ធ្វើ​សមកាលកម្ម​ធ្វើ​ស្ទើរតែ​ដូច​ជា​អសមកាល​ ហើយ​គ្រោង​ក្រាហ្វ​ខាងក្រោម (លក្ខខណ្ឌ​នៃ​ការ​សាកល្បង​គឺ​ដូច​គ្នា​នឹង​ចំណុច​ទី​បី​ដែរ — 200 អ្នក​ប្រើ)? 

Read My Stories

Buy Me a Coffee

សំឡេងនេះផលិតជាភាសាដើមនៃរឿង!

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

About Author

មតិយោបល់

ព្យួរស្លាក

អត្ថបទនេះត្រូវបានបង្ហាញនៅក្នុង

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps