កម្មវិធីបណ្តាញឥឡូវនេះត្រូវបានប្រើប្រាស់គ្រប់ទីកន្លែង ហើយក្នុងចំណោមពិធីការដឹកជញ្ជូនទាំងអស់ HTTP កាន់កាប់ចំណែករបស់សត្វតោ។ នៅពេលសិក្សាពីភាពខុសប្លែកគ្នានៃការអភិវឌ្ឍន៍កម្មវិធីគេហទំព័រ មនុស្សភាគច្រើនយកចិត្តទុកដាក់តិចតួចបំផុតចំពោះប្រព័ន្ធប្រតិបត្តិការដែលកម្មវិធីទាំងនេះដំណើរការពិតប្រាកដ។ ការបំបែកនៃការអភិវឌ្ឍន៍ (Dev) និងប្រតិបត្តិការ (Ops) ធ្វើឱ្យស្ថានភាពកាន់តែអាក្រក់ទៅៗ។ ប៉ុន្តែជាមួយនឹងការកើនឡើងនៃវប្បធម៌ DevOps អ្នកអភិវឌ្ឍន៍កំពុងមានទំនួលខុសត្រូវក្នុងការដំណើរការកម្មវិធីរបស់ពួកគេនៅក្នុងពពក ដូច្នេះវាមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់ពួកគេក្នុងការស្គាល់ច្បាស់អំពីផ្នែកខាងក្រោយនៃប្រព័ន្ធប្រតិបត្តិការ។ នេះមានប្រយោជន៍ជាពិសេសប្រសិនបើអ្នកកំពុងព្យាយាមដាក់ពង្រាយប្រព័ន្ធសម្រាប់ការតភ្ជាប់ដំណាលគ្នារាប់ពាន់ ឬរាប់ម៉ឺន។

ដែនកំណត់នៅក្នុងសេវាកម្មគេហទំព័រគឺស្រដៀងគ្នាទៅនឹងកម្មវិធីផ្សេងទៀតដែរ។ មិនថាវាជា load balancers ឬ database server ទេ កម្មវិធីទាំងអស់នេះមានបញ្ហាស្រដៀងគ្នានៅក្នុងបរិយាកាសដែលមានប្រសិទ្ធភាពខ្ពស់។ ការយល់ដឹងអំពីដែនកំណត់ជាមូលដ្ឋានទាំងនេះ និងវិធីយកឈ្នះលើពួកវាជាទូទៅ នឹងជួយអ្នកវាយតម្លៃការអនុវត្ត និងវិសាលភាពនៃកម្មវិធីគេហទំព័ររបស់អ្នក។

ខ្ញុំកំពុងសរសេរអត្ថបទស៊េរីនេះ ដើម្បីឆ្លើយតបទៅនឹងសំណួររបស់អ្នកអភិវឌ្ឍន៍វ័យក្មេងដែលចង់ក្លាយជាស្ថាបត្យករប្រព័ន្ធដែលមានព័ត៌មានល្អ។ វាមិនអាចទៅរួចទេក្នុងការយល់ដឹងយ៉ាងច្បាស់អំពីបច្ចេកទេសបង្កើនប្រសិទ្ធភាពកម្មវិធីលីនុចដោយមិនចាំបាច់ចូលទៅក្នុងមូលដ្ឋាននៃរបៀបដែលពួកគេធ្វើការនៅកម្រិតប្រព័ន្ធប្រតិបត្តិការ។ ទោះបីជាមានកម្មវិធីច្រើនប្រភេទក៏ដោយ ប៉ុន្តែនៅក្នុងស៊េរីនេះ ខ្ញុំចង់ស្វែងរកកម្មវិធីដែលមានមូលដ្ឋានលើបណ្តាញ ជាជាងកម្មវិធីលើតុ ដូចជាកម្មវិធីរុករកតាមអ៊ីនធឺណិត ឬកម្មវិធីនិពន្ធអត្ថបទ។ សម្ភារៈនេះត្រូវបានបម្រុងទុកសម្រាប់អ្នកអភិវឌ្ឍន៍ និងស្ថាបត្យករដែលចង់យល់ពីរបៀបដែលកម្មវិធីលីនុច ឬយូនីកដំណើរការ និងរបៀបរៀបចំរចនាសម្ព័ន្ធពួកវាសម្រាប់ដំណើរការខ្ពស់។

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

ខណៈពេលដែលអ្នកអាចប្រើចំណេះដឹងនេះដើម្បីបង្កើតកម្មវិធីមួយពីដំបូង ហើយវានឹងត្រូវបានធ្វើឱ្យប្រសើរយ៉ាងល្អឥតខ្ចោះ វាជាការល្អបំផុតដែលមិនត្រូវធ្វើវានោះទេ។ ប្រសិនបើអ្នកសរសេរម៉ាស៊ីនមេគេហទំព័រថ្មីនៅក្នុង C ឬ C++ សម្រាប់កម្មវិធីអាជីវកម្មរបស់ស្ថាប័នអ្នក នេះប្រហែលជាថ្ងៃចុងក្រោយរបស់អ្នកនៅលើការងារ។ ទោះជាយ៉ាងណាក៏ដោយការដឹងពីរចនាសម្ព័ន្ធនៃកម្មវិធីទាំងនេះនឹងជួយក្នុងការជ្រើសរើសកម្មវិធីដែលមានស្រាប់។ អ្នកនឹងអាចប្រៀបធៀបប្រព័ន្ធដំណើរការជាមួយនឹងប្រព័ន្ធដែលផ្អែកតាមខ្សែ ព្រមទាំងប្រព័ន្ធដែលផ្អែកលើព្រឹត្តិការណ៍។ អ្នកនឹងយល់ និងពេញចិត្តចំពោះមូលហេតុដែល Nginx ដំណើរការបានល្អជាង Apache httpd ហេតុអ្វីបានជាកម្មវិធី Python ដែលមានមូលដ្ឋានលើ Tornado អាចបម្រើអ្នកប្រើប្រាស់បានច្រើនជាងបើប្រៀបធៀបទៅនឹងកម្មវិធី Python ដែលមានមូលដ្ឋានលើ Django ។

ZeroHTTPd៖ ឧបករណ៍សិក្សា

ZeroHTTPd គឺជា web server ដែលខ្ញុំសរសេរពីដើមក្នុង C ជាឧបករណ៍បង្រៀន។ វាគ្មានភាពអាស្រ័យខាងក្រៅ រួមទាំងការចូលប្រើ Redis ផងដែរ។ យើងដំណើរការនីតិវិធី Redis ផ្ទាល់ខ្លួនរបស់យើង។ សូមមើលខាងក្រោមសម្រាប់ព័ត៌មានលម្អិតបន្ថែម។

ទោះបីជាយើងអាចពិភាក្សាទ្រឹស្តីបានយ៉ាងវែងក៏ដោយ គ្មានអ្វីប្រសើរជាងការសរសេរកូដ ដំណើរការវា និងការប្រៀបធៀបស្ថាបត្យកម្មម៉ាស៊ីនមេទាំងអស់ជាមួយគ្នាទៅវិញទៅមកនោះទេ។ នេះគឺជាវិធីសាស្រ្តជាក់ស្តែងបំផុត។ ដូច្នេះ យើងនឹងសរសេរម៉ាស៊ីនបម្រើបណ្ដាញ ZeroHTTPd សាមញ្ញមួយដោយប្រើម៉ូដែលនីមួយៗ៖ ដំណើរការផ្អែកលើខ្សែបណ្ដាញ និងផ្អែកលើព្រឹត្តិការណ៍។ តោះពិនិត្យមើលម៉ាស៊ីនមេនីមួយៗ ហើយមើលពីរបៀបដែលពួកវាដំណើរការបើប្រៀបធៀបនឹងគ្នា។ ZeroHTTPd ត្រូវបានអនុវត្តនៅក្នុងឯកសារ C តែមួយ រួមបញ្ចូលទាំងម៉ាស៊ីនបម្រើព្រឹត្តិការណ៍ utashការអនុវត្តតារាង hash ដ៏អស្ចារ្យដែលមាននៅក្នុងឯកសារបឋមកថាតែមួយ។ ក្នុងករណីផ្សេងទៀត វាមិនមានភាពអាស្រ័យ ដូច្នេះដើម្បីកុំឱ្យគម្រោងស្មុគស្មាញ។

មានមតិជាច្រើននៅក្នុងកូដដើម្បីជួយអ្នកយល់។ ក្នុងនាមជាម៉ាស៊ីនមេគេហទំព័រសាមញ្ញមួយនៅក្នុងជួរកូដមួយចំនួន ZeroHTTPd ក៏ជាក្របខ័ណ្ឌតិចតួចសម្រាប់ការអភិវឌ្ឍន៍គេហទំព័រផងដែរ។ វាមានមុខងារកំណត់ ប៉ុន្តែមានសមត្ថភាពបម្រើឯកសារឋិតិវន្ត និងទំព័រ "ថាមវន្ត" សាមញ្ញបំផុត។ ខ្ញុំត្រូវតែនិយាយថា ZeroHTTPd គឺល្អសម្រាប់ការរៀនពីរបៀបបង្កើតកម្មវិធីលីនុចដែលមានប្រសិទ្ធភាពខ្ពស់។ ជាទូទៅ សេវាកម្មគេហទំព័រភាគច្រើនរង់ចាំការស្នើសុំ ពិនិត្យមើលពួកវា និងដំណើរការវា។ នេះគឺជាអ្វីដែល ZeroHTTPd នឹងធ្វើ។ នេះជាឧបករណ៍សម្រាប់រៀន មិនមែនផលិតទេ។ វាមិនប្រសើរទេក្នុងការដោះស្រាយកំហុស ហើយទំនងជាមិនមានអំនួតតាមរយៈការអនុវត្តសុវត្ថិភាពល្អបំផុតទេ (អូបាទ ខ្ញុំបានប្រើ strcpy) ឬល្បិចដ៏ឆ្លាតវៃនៃភាសា C ប៉ុន្តែខ្ញុំសង្ឃឹមថាវាដំណើរការបានល្អ។

ទំព័រដើម ZeroHTTPd ។ វាអាចបញ្ចេញប្រភេទឯកសារផ្សេងៗគ្នា រួមទាំងរូបភាពផងដែរ។

ពាក្យស្នើសុំសៀវភៅភ្ញៀវ

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

កម្មវិធីបណ្តាញ "សៀវភៅភ្ញៀវ" ZeroHTTPd

បញ្ជរអ្នកទស្សនា និងធាតុសៀវភៅភ្ញៀវត្រូវបានរក្សាទុកនៅក្នុង Redis ។ សម្រាប់ការទំនាក់ទំនងជាមួយ Redis នីតិវិធីផ្ទាល់ខ្លួនត្រូវបានអនុវត្ត ពួកគេមិនអាស្រ័យលើបណ្ណាល័យខាងក្រៅទេ។ ខ្ញុំមិនមែនជាអ្នកគាំទ្រដ៏ធំនៃការចេញផ្សាយកូដ homebrew នៅពេលដែលមានដំណោះស្រាយជាសាធារណៈ និងត្រូវបានសាកល្បងយ៉ាងល្អ។ ប៉ុន្តែគោលបំណងរបស់ ZeroHTTPd គឺដើម្បីសិក្សាពីដំណើរការរបស់លីនុច និងការចូលប្រើសេវាកម្មខាងក្រៅ ខណៈពេលដែលការបម្រើសំណើ HTTP មានផលប៉ះពាល់ធ្ងន់ធ្ងរដល់ដំណើរការ។ យើងត្រូវតែគ្រប់គ្រងទំនាក់ទំនងយ៉ាងពេញលេញជាមួយ Redis នៅក្នុងស្ថាបត្យកម្មម៉ាស៊ីនមេនីមួយៗរបស់យើង។ នៅក្នុងស្ថាបត្យកម្មមួយចំនួន យើងប្រើការទប់ស្កាត់ការហៅទូរសព្ទ ហើយនៅក្នុងស្ថាបត្យកម្មផ្សេងទៀតយើងប្រើនីតិវិធីផ្អែកលើព្រឹត្តិការណ៍។ ការប្រើប្រាស់បណ្ណាល័យម៉ាស៊ីនភ្ញៀវ Redis ខាងក្រៅនឹងមិនផ្តល់ការគ្រប់គ្រងនេះទេ។ លើសពីនេះ អតិថិជន Redis តូចរបស់យើងគ្រាន់តែអនុវត្តមុខងារមួយចំនួនប៉ុណ្ណោះ (ការទទួលបាន ការកំណត់ និងការបង្កើនសោ ទទួល និងបន្ថែមទៅអារេ)។ លើសពីនេះទៀតពិធីការ Redis គឺឆើតឆាយនិងសាមញ្ញបំផុត។ អ្នកមិនចាំបាច់បង្រៀនវាជាពិសេសទេ។ ការពិតដែលពិធីការធ្វើការទាំងអស់នៅក្នុងកូដប្រហែលមួយរយបន្ទាត់បង្ហាញពីរបៀបដែលវាត្រូវបានគិតយ៉ាងល្អ។

តួលេខខាងក្រោមបង្ហាញពីអ្វីដែលកម្មវិធីធ្វើនៅពេលដែលអតិថិជន (កម្មវិធីរុករក) ស្នើសុំ /guestbookURL.

របៀបដែលកម្មវិធីសៀវភៅភ្ញៀវដំណើរការ

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

ស្ថាបត្យកម្មម៉ាស៊ីនមេ ZeroHTTPd

យើងកំពុងបង្កើតកំណែចំនួនប្រាំពីរនៃ ZeroHTTPd ជាមួយនឹងមុខងារដូចគ្នា ប៉ុន្តែស្ថាបត្យកម្មផ្សេងគ្នា៖

ដដែលៗ
ម៉ាស៊ីនមេ Fork (ដំណើរការកូនមួយក្នុងមួយសំណើ)
Pre-fork server (pre-forking of processes)
ម៉ាស៊ីនមេដែលមានខ្សែស្រឡាយប្រតិបត្តិ (ខ្សែស្រឡាយមួយក្នុងមួយសំណើ)
ម៉ាស៊ីនមេជាមួយការបង្កើតខ្សែស្រឡាយជាមុន
ស្ថាបត្យកម្មផ្អែកលើ poll()
ស្ថាបត្យកម្មផ្អែកលើ epoll

យើងវាស់ស្ទង់ដំណើរការនៃស្ថាបត្យកម្មនីមួយៗដោយការផ្ទុកម៉ាស៊ីនមេជាមួយនឹងសំណើ HTTP ។ ប៉ុន្តែនៅពេលប្រៀបធៀបស្ថាបត្យកម្មស្របគ្នាខ្ពស់ ចំនួននៃសំណួរកើនឡើង។ យើងសាកល្បងបីដងហើយគណនាជាមធ្យម។

វិធីសាស្រ្តសាកល្បង

ការដំឡើងការធ្វើតេស្តផ្ទុក ZeroHTTPd

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

តើម៉ាស៊ីនមេនីមួយៗនេះធ្វើអ្វី?

load.unixism.net៖ នេះជាកន្លែងដែលយើងដំណើរការ ab, ឧបករណ៍ប្រើប្រាស់ Apache Benchmark ។ វាបង្កើតបន្ទុកដែលត្រូវការដើម្បីសាកល្បងស្ថាបត្យកម្មម៉ាស៊ីនមេរបស់យើង។
nginx.unixism.net៖ ពេលខ្លះយើងចង់ដំណើរការកម្មវិធីម៉ាស៊ីនមេច្រើនជាងមួយ។ ដើម្បីធ្វើដូចនេះម៉ាស៊ីនមេ Nginx ដែលមានការកំណត់សមស្របដំណើរការជាឧបករណ៍ផ្ទុកតុល្យភាពដែលមកពី ab ចំពោះដំណើរការម៉ាស៊ីនមេរបស់យើង។
zerohttpd.unixism.net: នៅទីនេះយើងដំណើរការកម្មវិធីម៉ាស៊ីនមេរបស់យើងនៅលើស្ថាបត្យកម្មប្រាំពីរផ្សេងគ្នា មួយក្នុងពេលតែមួយ។
redis.unixism.net៖ ម៉ាស៊ីនមេនេះដំណើរការ Redis daemon ដែលធាតុសៀវភៅភ្ញៀវ និងបញ្ជរអ្នកទស្សនាត្រូវបានរក្សាទុក។

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

តើយើងវាស់អ្វី?

អ្នកអាចវាស់សូចនាករផ្សេងៗគ្នា។ យើងវាយតម្លៃដំណើរការនៃស្ថាបត្យកម្មនីមួយៗនៅក្នុងការកំណត់ដែលបានផ្តល់ឱ្យដោយការផ្ទុកម៉ាស៊ីនមេជាមួយនឹងសំណើនៅកម្រិតផ្សេងៗគ្នានៃភាពស្របគ្នា៖ ការផ្ទុកកើនឡើងពី 20 ទៅ 15 អ្នកប្រើប្រាស់ដំណាលគ្នា។

លទ្ធផលតេស្ត

តារាងខាងក្រោមបង្ហាញពីដំណើរការរបស់ម៉ាស៊ីនមេលើស្ថាបត្យកម្មផ្សេងៗគ្នានៅកម្រិតផ្សេងគ្នានៃភាពស្របគ្នា។ អ័ក្ស y គឺជាចំនួនសំណើក្នុងមួយវិនាទី អ័ក្ស x គឺជាការតភ្ជាប់ប៉ារ៉ាឡែល។

ខាងក្រោមនេះគឺជាតារាងដែលមានលទ្ធផល។

សំណើក្នុងមួយវិនាទី

ភាពស្របគ្នា
ដដែលៗ
សម
មុនសម
ស្ទ្រីម
ការផ្សាយជាមុន
ស្ទង់មតិ
epol

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
ការរីករាលដាលធំទូលាយ
2138

5000
-
ការរីករាលដាលធំទូលាយ
1600
1100
2519
-
2235

8000
-
-
1200
ការរីករាលដាលធំទូលាយ
2451
-
2100

១០.២៧៣
-
-
ការរីករាលដាលធំទូលាយ
-
2200
-
2200

១០.២៧៣
-
-
-
-
2200
-
2122

១០.២៧៣
-
-
-
-
970
-
1958

១០.២៧៣
-
-
-
-
730
-
1897

១០.២៧៣
-
-
-
-
590
-
1466

១០.២៧៣
-
-
-
-
532
-
1281

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

កូដប្រភព ZeroHTTPd

កូដប្រភព ZeroHTTPd នៅទីនេះ. មានថតដាច់ដោយឡែកសម្រាប់ស្ថាបត្យកម្មនីមួយៗ។

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking │ ├── main.c ├── ├── ការអាន 04_th 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ├── Makefile ├── public │ ─ │─ . png └── គំរូ └── សៀវភៅភ្ញៀវ └── index.html

បន្ថែមពីលើថតចំនួនប្រាំពីរសម្រាប់ស្ថាបត្យកម្មទាំងអស់ មានពីរបន្ថែមទៀតនៅក្នុងថតកម្រិតកំពូល៖ សាធារណៈ និងគំរូ។ ទីមួយមានឯកសារ index.html និងរូបភាពពីរូបថតអេក្រង់ដំបូង។ អ្នកអាចដាក់ឯកសារ និងថតផ្សេងទៀតនៅទីនោះ ហើយ ZeroHTTPd គួរតែបម្រើឯកសារឋិតិវន្តទាំងនោះដោយមិនមានបញ្ហាអ្វីឡើយ។ ប្រសិនបើផ្លូវនៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតត្រូវគ្នានឹងផ្លូវនៅក្នុងថតសាធារណៈនោះ ZeroHTTPd ស្វែងរកឯកសារ index.html នៅក្នុងថតនេះ។ ខ្លឹមសារសម្រាប់សៀវភៅភ្ញៀវត្រូវបានបង្កើតដោយថាមវន្ត។ វាមានតែទំព័រដើមប៉ុណ្ណោះ ហើយមាតិការបស់វាគឺផ្អែកលើឯកសារ 'templates/guestbook/index.html'។ ZeroHTTPd ងាយស្រួលបន្ថែមទំព័រថាមវន្តសម្រាប់ផ្នែកបន្ថែម។ គំនិតនេះគឺថាអ្នកប្រើប្រាស់អាចបន្ថែមគំរូទៅថតនេះ និងពង្រីក ZeroHTTPd តាមតម្រូវការ។

ដើម្បីបង្កើតម៉ាស៊ីនមេទាំងប្រាំពីរ សូមដំណើរការ make all ពីថតកម្រិតកំពូល - ហើយការស្ថាបនាទាំងអស់នឹងបង្ហាញនៅក្នុងថតនេះ។ ឯកសារដែលអាចប្រតិបត្តិបានរកមើលសាធារណៈ និងថតគំរូនៅក្នុងថតដែលពួកវាត្រូវបានដាក់ឱ្យដំណើរការ។

API លីនុច

អ្នកមិនចាំបាច់ត្រូវបាន versed យ៉ាងល្អនៅក្នុង Linux API ដើម្បីយល់ពីព័ត៌មាននៅក្នុងស៊េរីអត្ថបទនេះ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំសូមណែនាំឱ្យអានបន្ថែមលើប្រធានបទនេះ មានធនធានយោងជាច្រើននៅលើអ៊ីនធឺណិត។ ទោះបីជាយើងនឹងប៉ះលើប្រភេទមួយចំនួននៃ Linux APIs ក៏ដោយ ការផ្តោតរបស់យើងនឹងផ្តោតលើដំណើរការ ខ្សែស្រលាយ ព្រឹត្តិការណ៍ និងបណ្តាញជង់។ បន្ថែមពីលើសៀវភៅ និងអត្ថបទអំពីលីនុច API ខ្ញុំក៏សូមណែនាំឱ្យអានម៉ាណាសម្រាប់ការហៅទូរសព្ទប្រព័ន្ធ និងមុខងារបណ្ណាល័យដែលបានប្រើ។

ការអនុវត្ត និងការធ្វើមាត្រដ្ឋាន

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

កិច្ចការ CPU និង I/O

ជាចុងក្រោយ ក្នុងការគណនាតែងតែមានកិច្ចការពីរប្រភេទដែលអាចធ្វើទៅបាន៖ សម្រាប់ I/O និង CPU ។ ការទទួលសំណើតាមអ៊ីនធឺណិត (បណ្តាញ I/O) ការបម្រើឯកសារ (បណ្តាញ និងថាស I/O) ការទំនាក់ទំនងជាមួយមូលដ្ឋានទិន្នន័យ (បណ្តាញ និងថាស I/O) គឺជាសកម្មភាព I/O ទាំងអស់។ សំណួរមូលដ្ឋានទិន្នន័យមួយចំនួនអាចជា CPU ដែលពឹងផ្អែកខ្លាំងបន្តិច (ការតម្រៀប ជាមធ្យមមួយលានលទ្ធផល។ល។)។ កម្មវិធីគេហទំព័រភាគច្រើនត្រូវបានកំណត់ដោយ I/O អតិបរមាដែលអាចធ្វើទៅបាន ហើយខួរក្បាលកម្រត្រូវបានប្រើក្នុងសមត្ថភាពពេញលេញ។ នៅពេលអ្នកឃើញថាកិច្ចការ I/O មួយចំនួនកំពុងប្រើ CPU ច្រើន វាទំនងជាសញ្ញានៃស្ថាបត្យកម្មកម្មវិធីខ្សោយ។ នេះអាចមានន័យថាធនធាន CPU ត្រូវបានខ្ជះខ្ជាយលើការគ្រប់គ្រងដំណើរការ និងការប្តូរបរិបទ ហើយវាមិនមានប្រយោជន៍ទាំងស្រុងនោះទេ។ ប្រសិនបើអ្នកកំពុងធ្វើអ្វីមួយដូចជា ដំណើរការរូបភាព ការបំលែងឯកសារអូឌីយ៉ូ ឬការរៀនម៉ាស៊ីន នោះកម្មវិធីត្រូវការធនធាន CPU ដ៏មានឥទ្ធិពល។ ប៉ុន្តែសម្រាប់កម្មវិធីភាគច្រើននេះមិនមែនជាករណីនោះទេ។

ស្វែងយល់បន្ថែមអំពីស្ថាបត្យកម្មម៉ាស៊ីនមេ

ប្រភព: www.habr.com

ដំណើរការកម្មវិធីបណ្តាញលីនុច។ សេចក្តីផ្តើម