សមរភូមិនៃម៉ាស៊ីនមេគេហទំព័រ។ ផ្នែកទី 2 - សេណារីយ៉ូ HTTPS ប្រាកដនិយម៖

យើងបាននិយាយអំពីបច្ចេកទេសនៅក្នុង ផ្នែកដំបូង។ អត្ថបទនេះ យើងសាកល្បង HTTPS ប៉ុន្តែនៅក្នុងសេណារីយ៉ូជាក់ស្តែងជាងនេះ។ សម្រាប់ការធ្វើតេស្ត យើងទទួលបានវិញ្ញាបនបត្រ Let's Encrypt និងបើកការបង្ហាប់ Brotli ដល់ 11។

លើកនេះយើងនឹងព្យាយាមផលិតឡើងវិញនូវសេណារីយ៉ូនៃការដាក់ពង្រាយម៉ាស៊ីនមេនៅលើ VDS ឬជាម៉ាស៊ីននិម្មិតនៅលើម៉ាស៊ីនដែលមានប្រព័ន្ធដំណើរការស្តង់ដារ។ ចំពោះគោលបំណងនេះ ដែនកំណត់ត្រូវបានកំណត់នៅ៖

• 25% - ដែលស្មើនឹងប្រេកង់ ~ 1350 MHz
• 35% -1890MHz
• 41% - 2214 MHz
• 65% - 3510 MHz

ចំនួននៃការតភ្ជាប់តែមួយដងត្រូវបានកាត់បន្ថយពី 500 ទៅ 1, 3, 5, 7 និង 9 ។

លទ្ធផល៖

ការពន្យារពេល៖

TTFB ត្រូវ​បាន​រួម​បញ្ចូល​ជា​ពិសេស​ជា​ការ​ធ្វើ​តេ​ស្ត​ដោយ​ឡែក​ពី​គ្នា​ដោយ​សារ​តែ HTTPD Tools បង្កើត​អ្នក​ប្រើ​ថ្មី​សម្រាប់​សំណើ​បុគ្គល​នីមួយៗ។ ការធ្វើតេស្តនេះនៅតែដាច់ឆ្ងាយពីការពិត ពីព្រោះអ្នកប្រើប្រាស់នឹងនៅតែចុចពីរបីទំព័រ ហើយតាមពិត TTFP នឹងដើរតួនាទីសំខាន់។

ទីមួយ ជាទូទៅសំណើដំបូងបំផុតបន្ទាប់ពីការចាប់ផ្តើមដំបូងនៃម៉ាស៊ីននិម្មិត IIS ចំណាយពេលជាមធ្យម 120 ms ។

សំណើជាបន្តបន្ទាប់ទាំងអស់បង្ហាញ TTFP នៃ 1.5 ms ។ Apache និង Nginx មានភាពយឺតយ៉ាវក្នុងរឿងនេះ។ ដោយផ្ទាល់ អ្នកនិពន្ធចាត់ទុកការសាកល្បងនេះថាជាការលាតត្រដាងបំផុត ហើយនឹងជ្រើសរើសអ្នកឈ្នះដោយផ្អែកលើវាតែប៉ុណ្ណោះ។
លទ្ធផលគឺមិនគួរឱ្យភ្ញាក់ផ្អើលទេចាប់តាំងពីឃ្លាំងសម្ងាត់ IIS បានបង្ហាប់មាតិកាឋិតិវន្តរួចហើយហើយមិនបង្ហាប់វារាល់ពេលដែលវាត្រូវបានចូលប្រើ។

ពេលវេលាចំណាយសម្រាប់អតិថិជនម្នាក់ៗ

ដើម្បីវាយតម្លៃការអនុវត្ត ការធ្វើតេស្តដែលមានការតភ្ជាប់តែមួយគឺគ្រប់គ្រាន់ហើយ។
ឧទាហរណ៍ IIS បានបញ្ចប់ការសាកល្បងលើអ្នកប្រើប្រាស់ 5000 នាក់ក្នុងរយៈពេល 40 វិនាទី ដែលស្មើនឹង 123 សំណើក្នុងមួយវិនាទី។

ក្រាហ្វខាងក្រោមបង្ហាញពីពេលវេលារហូតដល់មាតិកាគេហទំព័រត្រូវបានផ្ទេរទាំងស្រុង។ នេះគឺជាសមាមាត្រនៃសំណើដែលបានបំពេញក្នុងរយៈពេលដែលបានផ្តល់ឱ្យ។ ក្នុងករណីរបស់យើង 80% នៃសំណើទាំងអស់ត្រូវបានដំណើរការក្នុង 8ms នៅលើ IIS និងក្នុង 4.5ms នៅលើ Apache និង Nginx ហើយ 8% នៃសំណើទាំងអស់នៅលើ Apache និង Nginx ត្រូវបានបញ្ចប់ក្នុងចន្លោះពេលរហូតដល់ 98 មីលីវិនាទី។

ពេលវេលាដែលសំណើចំនួន 5000 ត្រូវបានដំណើរការ៖

ពេលវេលាដែលសំណើចំនួន 5000 ត្រូវបានដំណើរការ៖

ប្រសិនបើអ្នកមានម៉ាស៊ីននិម្មិតដែលមាន CPU 3.5GHz និង 8 cores បន្ទាប់មកជ្រើសរើសអ្វីដែលអ្នកចង់បាន។ ម៉ាស៊ីនមេគេហទំព័រទាំងអស់គឺស្រដៀងគ្នាខ្លាំងណាស់នៅក្នុងការធ្វើតេស្តនេះ។ យើងនឹងនិយាយអំពីម៉ាស៊ីនមេគេហទំព័រណាមួយដែលត្រូវជ្រើសរើសសម្រាប់ម៉ាស៊ីននីមួយៗខាងក្រោម។

នៅពេលដែលវាមកដល់ស្ថានភាពជាក់ស្តែងបន្តិច នោះម៉ាស៊ីនមេគេហទំព័រទាំងអស់នឹងឆ្ពោះទៅមុខ។

ធាតុចូល៖

ក្រាហ្វនៃការពន្យាពេលធៀបនឹងចំនួននៃការតភ្ជាប់ក្នុងពេលដំណាលគ្នា។ រលោងនិងទាបជាងគឺល្អជាង។ 2% ចុងក្រោយ​ត្រូវ​បាន​យក​ចេញ​ពី​តារាង​ព្រោះ​វា​នឹង​ធ្វើ​ឱ្យ​ពួកគេ​មិន​អាច​អាន​បាន។

ឥឡូវនេះសូមពិចារណាជម្រើសដែលម៉ាស៊ីនមេត្រូវបានបង្ហោះនៅលើការបង្ហោះនិម្មិត។ ចូរយក 4 ស្នូលនៅ 2.2 GHz និងស្នូលមួយនៅ 1.8 GHz ។

របៀបធ្វើមាត្រដ្ឋាន

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

ពីមុនបញ្ហាប្រឈមទាំងមូលគឺដើម្បីដំណើរការ 98% នៃសំណើដែលមានភាពយឺតយ៉ាវទាបបំផុតសម្រាប់សំណើទាំងអស់ ដោយរក្សាខ្សែកោងឱ្យរាបស្មើតាមដែលអាចធ្វើទៅបាន។ ឥឡូវនេះ តាមរយៈការសាងសង់ខ្សែកោងមួយទៀត យើងនឹងរកឃើញចំណុចប្រតិបត្តិការដ៏ល្អប្រសើរសម្រាប់ម៉ាស៊ីនមេនីមួយៗ។

ដើម្បីធ្វើដូចនេះសូមយកសូចនាករសំណើក្នុងមួយវិនាទី (RPR) ។ ផ្ដេកគឺជាប្រេកង់ បញ្ឈរគឺជាចំនួនសំណើដែលបានដំណើរការក្នុងមួយវិនាទី បន្ទាត់គឺជាចំនួនស្នូល។

បង្ហាញការជាប់ទាក់ទងគ្នានៃរបៀបដែលដំណើរការ Nginx ស្នើសុំមួយបន្ទាប់ពីមួយផ្សេងទៀត។ 8 cores ដំណើរការបានប្រសើរជាងនៅក្នុងការធ្វើតេស្តនេះ។

ក្រាហ្វនេះបង្ហាញយ៉ាងច្បាស់ថាតើ Nginx ដំណើរការល្អជាង (មិនច្រើនទេ) នៅលើស្នូលតែមួយ។ ប្រសិនបើអ្នកមាន Nginx អ្នកគួរតែពិចារណាកាត់បន្ថយចំនួនស្នូលទៅមួយ ប្រសិនបើអ្នកកំពុងបង្ហោះតែឋិតិវន្ត។

IIS ទោះបីជាវាមាន TTFB ទាបបំផុតយោងទៅតាម DevTools នៅក្នុង Chrome ក៏ដោយ ក៏គ្រប់គ្រងចាញ់ទាំង Nginx និង Apache ក្នុងការប្រយុទ្ធយ៉ាងធ្ងន់ធ្ងរជាមួយនឹងការធ្វើតេស្តភាពតានតឹងពី Apache Foundation ។

រាល់​ការ​កោង​នៃ​ក្រាហ្វ​ត្រូវ​បាន​ផលិត​ឡើង​វិញ​ដោយ​ក្រណាត់​ដែក។

ប្រភេទនៃការសន្និដ្ឋានមួយចំនួន៖

បាទ Apache ដំណើរការកាន់តែអាក្រក់នៅលើ 1 និង 8 cores ប៉ុន្តែដំណើរការប្រសើរជាងបន្តិចនៅលើ 4 ។

បាទ/ចាស ដំណើរការ Nginx នៅលើ 8 cores ស្នើរសុំឱ្យប្រសើរជាងមុននៅលើ 1 និង 4 cores ហើយដំណើរការកាន់តែអាក្រក់នៅពេលដែលមានការតភ្ជាប់ច្រើន។

បាទ/ចាស IIS ចូលចិត្ត 4 cores សម្រាប់បន្ទុកការងារច្រើនខ្សែ ហើយចូលចិត្ត 8 cores សម្រាប់បន្ទុកការងារតែមួយ។ ទីបំផុត IIS លឿនជាងអ្នកផ្សេងបន្តិចនៅលើ 8 cores ក្រោមការផ្ទុកខ្ពស់ ទោះបីជាម៉ាស៊ីនមេទាំងអស់ស្មើគ្នាក៏ដោយ។

នេះមិនមែនជាកំហុសរង្វាស់ទេ កំហុសនៅទីនេះគឺមិនលើសពី +-1ms ទេ។ ក្នុងការពន្យារពេល និងមិនលើសពី +- 2-3 សំណើក្នុងមួយវិនាទីសម្រាប់ RPR ។

លទ្ធផលដែល 8 cores ដំណើរការកាន់តែអាក្រក់គឺមិនគួរឱ្យភ្ញាក់ផ្អើលនោះទេ cores ជាច្រើន និង SMT/Hyperthreading ធ្វើឱ្យខូចដំណើរការយ៉ាងខ្លាំង ប្រសិនបើយើងមានពេលវេលាដែលយើងត្រូវបំពេញបំពង់ទាំងមូល។

ប្រភព: www.habr.com