ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ໃນປັດຈຸບັນຖືກນໍາໃຊ້ຢູ່ທົ່ວທຸກແຫ່ງ, ແລະໃນບັນດາໂປໂຕຄອນການຂົນສົ່ງທັງຫມົດ, HTTP ຄອບຄອງສ່ວນແບ່ງຂອງຊ້າງ. ໃນເວລາທີ່ການສຶກສາ nuances ຂອງການພັດທະນາຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌, ປະຊາຊົນສ່ວນໃຫຍ່ເອົາໃຈໃສ່ພຽງເລັກນ້ອຍຫຼາຍກັບລະບົບປະຕິບັດການທີ່ຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ເຮັດວຽກຕົວຈິງ. ການແຍກການພັດທະນາ (Dev) ແລະການດໍາເນີນງານ (Ops) ພຽງແຕ່ເຮັດໃຫ້ສະຖານະການຮ້າຍແຮງຂຶ້ນ. ແຕ່ດ້ວຍການເຕີບໃຫຍ່ຂອງວັດທະນະທໍາ DevOps, ນັກພັດທະນາກາຍເປັນຜູ້ຮັບຜິດຊອບໃນການເຮັດວຽກຂອງແອັບພລິເຄຊັນຂອງພວກເຂົາຢູ່ໃນເມຄ, ດັ່ງນັ້ນມັນເປັນປະໂຫຍດຫຼາຍສໍາລັບພວກເຂົາທີ່ຈະຄຸ້ນເຄີຍກັບ backend ຂອງລະບົບປະຕິບັດການ. ນີ້ແມ່ນເປັນປະໂຫຍດໂດຍສະເພາະຖ້າຫາກວ່າທ່ານກໍາລັງພະຍາຍາມທີ່ຈະນໍາໃຊ້ລະບົບສໍາລັບພັນຫຼືຫຼາຍສິບພັນຂອງການເຊື່ອມຕໍ່ພ້ອມໆກັນ.

ຂໍ້ຈໍາກັດໃນການບໍລິການເວັບແມ່ນຄ້າຍຄືກັນກັບຄໍາຮ້ອງສະຫມັກອື່ນໆ. ບໍ່ວ່າຈະເປັນ load balancers ຫຼືເຄື່ອງແມ່ຂ່າຍຂອງຖານຂໍ້ມູນ, ຄໍາຮ້ອງສະຫມັກທັງຫມົດເຫຼົ່ານີ້ມີບັນຫາທີ່ຄ້າຍຄືກັນໃນສະພາບແວດລ້ອມທີ່ມີປະສິດທິພາບສູງ. ການເຂົ້າໃຈຂໍ້ຈໍາກັດພື້ນຖານເຫຼົ່ານີ້ແລະວິທີການເອົາຊະນະພວກມັນໂດຍທົ່ວໄປຈະຊ່ວຍໃຫ້ທ່ານປະເມີນປະສິດທິພາບແລະຂະຫນາດຂອງຄໍາຮ້ອງສະຫມັກເວັບຂອງທ່ານ.

ຂ້ອຍກໍາລັງຂຽນບົດຄວາມຊຸດນີ້ເພື່ອຕອບຄໍາຖາມຈາກຜູ້ພັດທະນາໄວຫນຸ່ມທີ່ຕ້ອງການກາຍເປັນນັກສະຖາປະນິກລະບົບທີ່ມີຂໍ້ມູນດີ. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບເຕັກນິກການເພີ່ມປະສິດທິພາບຂອງແອັບພລິເຄຊັນ Linux ໂດຍບໍ່ຕ້ອງເຂົ້າໄປໃນພື້ນຖານຂອງວິທີການເຮັດວຽກໃນລະດັບລະບົບປະຕິບັດການ. ເຖິງແມ່ນວ່າມີຫຼາຍປະເພດຂອງຄໍາຮ້ອງສະຫມັກ, ໃນຊຸດນີ້ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະຄົ້ນຫາຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ແທນທີ່ຈະກ່ວາຄໍາຮ້ອງສະຫມັກ desktop ເຊັ່ນຕົວທ່ອງເວັບຫຼືຕົວແກ້ໄຂຂໍ້ຄວາມ. ເອກະສານນີ້ແມ່ນມີຈຸດປະສົງສໍາລັບນັກພັດທະນາແລະສະຖາປະນິກທີ່ຕ້ອງການເຂົ້າໃຈວິທີການເຮັດວຽກຂອງ Linux ຫຼື Unix ແລະໂຄງສ້າງພວກມັນເພື່ອໃຫ້ມີປະສິດທິພາບສູງ.

Linux ແມ່ນ ຫ້ອງເຊີບເວີ ລະ​ບົບ​ປະ​ຕິ​ບັດ​ການ​, ແລະ​ສ່ວນ​ໃຫຍ່​ແລ້ວ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂອງ​ທ່ານ​ດໍາ​ເນີນ​ການ​ກ່ຽວ​ກັບ OS ນີ້​. ເຖິງແມ່ນວ່າຂ້ອຍເວົ້າວ່າ "Linux", ສ່ວນໃຫຍ່ຂອງເວລາທີ່ເຈົ້າສາມາດສົມມຸດໄດ້ຢ່າງປອດໄພວ່າຂ້ອຍຫມາຍເຖິງທຸກລະບົບປະຕິບັດການທີ່ຄ້າຍຄືກັບ Unix ໂດຍທົ່ວໄປ. ຢ່າງໃດກໍ່ຕາມ, ຂ້ອຍບໍ່ໄດ້ທົດສອບລະຫັດທີ່ມາພ້ອມກັບລະບົບອື່ນໆ. ດັ່ງນັ້ນ, ຖ້າທ່ານສົນໃຈ FreeBSD ຫຼື OpenBSD, ຜົນໄດ້ຮັບຂອງທ່ານອາດຈະແຕກຕ່າງກັນ. ເມື່ອຂ້ອຍລອງບາງສິ່ງບາງຢ່າງສະເພາະ Linux, ຂ້ອຍຊີ້ມັນອອກ.

ໃນຂະນະທີ່ທ່ານສາມາດນໍາໃຊ້ຄວາມຮູ້ນີ້ເພື່ອສ້າງ app ຈາກ scratch ແລະມັນຈະໄດ້ຮັບການ optimized ຢ່າງສົມບູນ, ມັນດີທີ່ສຸດທີ່ຈະບໍ່ເຮັດແນວນັ້ນ. ຖ້າທ່ານຂຽນເຄື່ອງແມ່ຂ່າຍເວັບໃຫມ່ໃນ C ຫຼື C ++ ສໍາລັບຄໍາຮ້ອງສະຫມັກທຸລະກິດຂອງອົງການຂອງທ່ານ, ນີ້ອາດຈະເປັນມື້ສຸດທ້າຍຂອງທ່ານໃນການເຮັດວຽກ. ຢ່າງໃດກໍ່ຕາມ, ການຮູ້ໂຄງສ້າງຂອງແອັບພລິເຄຊັນເຫຼົ່ານີ້ຈະຊ່ວຍເລືອກໂປຼແກຼມທີ່ມີຢູ່. ທ່ານ​ຈະ​ສາ​ມາດ​ປຽບ​ທຽບ​ລະ​ບົບ​ທີ່​ອີງ​ໃສ່​ຂະ​ບວນ​ການ​ກັບ​ລະ​ບົບ​ທີ່​ອີງ​ໃສ່​ກະ​ທູ້​ເຊັ່ນ​ດຽວ​ກັນ​ກັບ​ການ​ທີ່​ອີງ​ໃສ່​ເຫດ​ການ​. ທ່ານຈະເຂົ້າໃຈແລະຮູ້ບຸນຄຸນວ່າເປັນຫຍັງ Nginx ປະຕິບັດໄດ້ດີກວ່າ Apache httpd, ເປັນຫຍັງແອັບພລິເຄຊັນ Python ທີ່ອີງໃສ່ Tornado ສາມາດໃຫ້ບໍລິການຜູ້ໃຊ້ໄດ້ຫຼາຍກວ່າເມື່ອທຽບໃສ່ກັບແອັບພລິເຄຊັນ Python ຂອງ Django.

ZeroHTTPd: ເຄື່ອງມືການຮຽນຮູ້

ZeroHTTPd ແມ່ນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ທີ່ຂ້າພະເຈົ້າຂຽນຈາກ scratch ໃນ C ເປັນເຄື່ອງມືການສອນ. ມັນບໍ່ມີການຂື້ນກັບພາຍນອກ, ລວມທັງການເຂົ້າເຖິງ Redis. ພວກເຮົາດໍາເນີນການຂັ້ນຕອນ Redis ຂອງພວກເຮົາເອງ. ເບິ່ງຂ້າງລຸ່ມນີ້ສໍາລັບລາຍລະອຽດເພີ່ມເຕີມ.

ເຖິງແມ່ນວ່າພວກເຮົາສາມາດສົນທະນາທິດສະດີໃນຄວາມຍາວ, ບໍ່ມີຫຍັງດີກ່ວາການຂຽນລະຫັດ, ແລ່ນມັນ, ແລະປຽບທຽບສະຖາປັດຕະຍະກໍາຂອງເຄື່ອງແມ່ຂ່າຍທັງຫມົດກັບກັນແລະກັນ. ນີ້ແມ່ນວິທີການທີ່ຈະແຈ້ງທີ່ສຸດ. ດັ່ງນັ້ນ, ພວກເຮົາຈະຂຽນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ ZeroHTTPd ແບບງ່າຍດາຍໂດຍໃຊ້ແຕ່ລະແບບ: ຂະບວນການ, ອີງໃສ່ກະທູ້, ແລະເຫດການ. ໃຫ້ກວດເບິ່ງແຕ່ລະເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້ແລະເບິ່ງວ່າພວກເຂົາປະຕິບັດແນວໃດເມື່ອປຽບທຽບກັບກັນແລະກັນ. ZeroHTTPd ຖືກປະຕິບັດຢູ່ໃນໄຟລ໌ C ດຽວ. ເຊີບເວີທີ່ອີງໃສ່ເຫດການປະກອບມີ utash, ການປະຕິບັດຕາຕະລາງ hash ທີ່ຍິ່ງໃຫຍ່ທີ່ມາໃນໄຟລ໌ header ດຽວ. ໃນກໍລະນີອື່ນໆ, ບໍ່ມີການເພິ່ງພາອາໄສ, ເພື່ອບໍ່ໃຫ້ໂຄງການສັບສົນ.

ມີຫຼາຍຄໍາຄິດເຫັນໃນລະຫັດເພື່ອຊ່ວຍໃຫ້ທ່ານເຂົ້າໃຈ. ເປັນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ທີ່ງ່າຍດາຍໃນສອງສາມເສັ້ນຂອງລະຫັດ, ZeroHTTPd ຍັງເປັນກອບຫນ້ອຍສໍາລັບການພັດທະນາເວັບ. ມັນມີຫນ້າທີ່ຈໍາກັດ, ແຕ່ສາມາດຮັບໃຊ້ໄຟລ໌ຄົງທີ່ແລະຫນ້າ "dynamic" ທີ່ງ່າຍດາຍຫຼາຍ. ຂ້ອຍຕ້ອງເວົ້າວ່າ ZeroHTTPd ແມ່ນດີສໍາລັບການຮຽນຮູ້ວິທີການສ້າງຄໍາຮ້ອງສະຫມັກ Linux ທີ່ມີປະສິດທິພາບສູງ. ໂດຍແລະຂະຫນາດໃຫຍ່, ການບໍລິການເວັບໄຊຕ໌ສ່ວນໃຫຍ່ລໍຖ້າການຮ້ອງຂໍ, ກວດເບິ່ງພວກເຂົາແລະດໍາເນີນການ. ນີ້ແມ່ນສິ່ງທີ່ ZeroHTTPd ຈະເຮັດ. ນີ້ແມ່ນເຄື່ອງມືສໍາລັບການຮຽນຮູ້, ບໍ່ແມ່ນການຜະລິດ. ມັນບໍ່ແມ່ນສິ່ງທີ່ດີໃນການຈັດການຄວາມຜິດພາດແລະເບິ່ງຄືວ່າຈະບໍ່ເວົ້າໂອ້ອວດການປະຕິບັດຄວາມປອດໄພທີ່ດີທີ່ສຸດ (ໂອ້, ຂ້ອຍເຄີຍໃຊ້ strcpy) ຫຼື tricks ສະຫລາດຂອງພາສາ C. ແຕ່ຂ້າພະເຈົ້າຫວັງວ່າມັນຈະເຮັດວຽກໄດ້ດີ.

ຫນ້າທໍາອິດ ZeroHTTPd. ມັນ​ສາ​ມາດ​ອອກ​ປະ​ເພດ​ໄຟລ​໌​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ລວມ​ທັງ​ຮູບ​ພາບ​

ໃບສະໝັກຈອງແຂກ

ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ທັນສະໄຫມມັກຈະບໍ່ຈໍາກັດພຽງແຕ່ໄຟລ໌ຄົງທີ່. ພວກເຂົາເຈົ້າມີປະຕິສໍາພັນທີ່ສັບສົນກັບຖານຂໍ້ມູນຕ່າງໆ, ຖານຄວາມຈໍາ, ແລະອື່ນໆ. ດັ່ງນັ້ນພວກເຮົາຈະສ້າງຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ງ່າຍດາຍທີ່ເອີ້ນວ່າ "Guest Book" ບ່ອນທີ່ນັກທ່ອງທ່ຽວອອກຈາກລາຍການພາຍໃຕ້ຊື່ຂອງພວກເຂົາ. ປື້ມບັນທຶກຂອງແຂກທີ່ເກັບຮັກສາໄວ້ກ່ອນຫນ້າ. ນອກນັ້ນຍັງມີເຄົາເຕີຂອງຜູ້ເຂົ້າຊົມຢູ່ດ້ານລຸ່ມຂອງຫນ້າ.

ແອັບພລິເຄຊັນເວັບ "Guest Book" ZeroHTTPd

ເຄົາເຕີ້ຜູ້ເຂົ້າຊົມ ແລະລາຍການປື້ມບັນທຶກແຂກຖືກເກັບໄວ້ໃນ Redis. ສໍາລັບການສື່ສານກັບ Redis, ຂັ້ນຕອນຂອງຕົນເອງໄດ້ຖືກປະຕິບັດ; ພວກມັນບໍ່ຂຶ້ນກັບຫ້ອງສະຫມຸດພາຍນອກ. ຂ້ອຍບໍ່ແມ່ນແຟນໃຫຍ່ຂອງການອອກລະຫັດ homebrew ເມື່ອມີການແກ້ໄຂສາທາລະນະແລະທົດສອບດີ. ແຕ່ຈຸດປະສົງຂອງ ZeroHTTPd ແມ່ນເພື່ອສຶກສາການປະຕິບັດຂອງ Linux ແລະການເຂົ້າເຖິງການບໍລິການພາຍນອກ, ໃນຂະນະທີ່ການໃຫ້ບໍລິການຄໍາຮ້ອງຂໍ HTTP ມີຜົນກະທົບອັນຮ້າຍແຮງ. ພວກເຮົາຕ້ອງຄວບຄຸມການສື່ສານກັບ Redis ຢ່າງເຕັມສ່ວນໃນແຕ່ລະສະຖາປັດຕະຍະກໍາຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ. ໃນບາງສະຖາປັດຕະຍະກໍາທີ່ພວກເຮົາໃຊ້ການຂັດຂວາງການໂທ, ໃນບາງສະຖາປັດຕະຍະກໍາພວກເຮົາໃຊ້ຂັ້ນຕອນການອີງໃສ່ເຫດການ. ການນໍາໃຊ້ຫ້ອງສະຫມຸດລູກຄ້າ Redis ພາຍນອກຈະບໍ່ສະຫນອງການຄວບຄຸມນີ້. ນອກຈາກນັ້ນ, ລູກຄ້າ Redis ພຽງເລັກນ້ອຍຂອງພວກເຮົາພຽງແຕ່ປະຕິບັດຫນ້າທີ່ບໍ່ຫຼາຍປານໃດ (ການໄດ້ຮັບ, ການຕັ້ງຄ່າ, ແລະການເພີ່ມລະຫັດ; ການຮັບແລະການຕື່ມໃສ່ກັບ array). ນອກຈາກນັ້ນ, ອະນຸສັນຍາ Redis ແມ່ນສະຫງ່າງາມແລະງ່າຍດາຍທີ່ສຸດ. ເຈົ້າບໍ່ ຈຳ ເປັນຕ້ອງສອນມັນໂດຍສະເພາະ. ຄວາມຈິງທີ່ວ່າໂປໂຕຄອນເຮັດວຽກທັງຫມົດໃນປະມານຮ້ອຍເສັ້ນຂອງລະຫັດສະແດງໃຫ້ເຫັນວ່າມັນຄິດໄດ້ດີປານໃດ.

ຕົວເລກຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນສິ່ງທີ່ແອັບພລິເຄຊັນເຮັດເມື່ອລູກຄ້າ (ຕົວທ່ອງເວັບ) ຮ້ອງຂໍ /guestbookURL.

ຄໍາຮ້ອງສະຫມັກປື້ມບັນທຶກແຂກເຮັດວຽກແນວໃດ

ໃນເວລາທີ່ຫນ້າປື້ມບັນທຶກແຂກຕ້ອງການອອກ, ມີການໂທຫາລະບົບໄຟລ໌ຫນຶ່ງເພື່ອອ່ານແມ່ແບບເຂົ້າໄປໃນຫນ່ວຍຄວາມຈໍາແລະສາມໂທຫາເຄືອຂ່າຍ Redis. ໄຟລ໌ແມ່ແບບປະກອບມີເນື້ອຫາ HTML ສ່ວນໃຫຍ່ສໍາລັບຫນ້າໃນຫນ້າຈໍຂ້າງເທິງ. ຍັງມີຕົວຍຶດພິເສດສໍາລັບສ່ວນແບບເຄື່ອນໄຫວຂອງເນື້ອຫາ: ຂໍ້ຄວາມແລະຕົວນັບຈໍານວນຜູ້ເຂົ້າຊົມ. ພວກເຮົາໄດ້ຮັບພວກມັນຈາກ Redis, ໃສ່ພວກມັນເຂົ້າໄປໃນຫນ້າແລະໃຫ້ລູກຄ້າມີເນື້ອຫາເຕັມຮູບແບບ. ການໂທຫາ Redis ທີສາມສາມາດຫຼີກເວັ້ນໄດ້ເພາະວ່າ Redis ສົ່ງຄືນຄ່າທີ່ສໍາຄັນໃຫມ່ເມື່ອເພີ່ມຂຶ້ນ. ແນວໃດກໍ່ຕາມ, ສໍາລັບເຊີບເວີຂອງພວກເຮົາ, ທີ່ມີສະຖາປັດຕະຍະກຳທີ່ອີງໃສ່ເຫດການບໍ່ກົງກັນ, ການໂທຫາເຄືອຂ່າຍຫຼາຍແມ່ນເປັນການທົດສອບທີ່ດີເພື່ອຈຸດປະສົງການຮຽນຮູ້. ດັ່ງນັ້ນພວກເຮົາຍົກເລີກມູນຄ່າຄືນຂອງ Redis ຂອງຈໍານວນຜູ້ມາຢ້ຽມຢາມແລະສອບຖາມມັນດ້ວຍການໂທແຍກຕ່າງຫາກ.

ສະຖາປັດຕະຍະກຳເຊີບເວີ ZeroHTTPd

ພວກເຮົາກຳລັງສ້າງ XNUMX ລຸ້ນ ZeroHTTPd ທີ່ມີໜ້າວຽກດຽວກັນ ແຕ່ສະຖາປັດຕະຍະກຳທີ່ແຕກຕ່າງກັນ:

• ຊ້ຳ
• ເຊີບເວີຂອງສ້ອມ (ຂັ້ນຕອນໜຶ່ງລູກຕໍ່ການຮ້ອງຂໍ)
• Pre-fork server (pre-fork of processes)
• ເຊີບເວີທີ່ມີກະທູ້ປະຕິບັດ (ຫນຶ່ງຫົວຂໍ້ຕໍ່ຄໍາຮ້ອງຂໍ)
• ເຊີບເວີທີ່ມີການສ້າງກະທູ້ກ່ອນ
• ສະຖາປັດຕະຍະກໍາ poll()
• ສະຖາປັດຕະຍະກໍາ epoll

ພວກເຮົາວັດແທກປະສິດທິພາບຂອງແຕ່ລະສະຖາປັດຕະຍະກໍາໂດຍການໂຫຼດເຄື່ອງແມ່ຂ່າຍທີ່ມີຄໍາຮ້ອງຂໍ HTTP. ແຕ່ເມື່ອປຽບທຽບສະຖາປັດຕະຍະກໍາຂະຫນານສູງ, ຈໍານວນການສອບຖາມເພີ່ມຂຶ້ນ. ພວກເຮົາທົດສອບສາມຄັ້ງແລະຄິດໄລ່ສະເລ່ຍ.

ວິທີການທົດສອບ

ການຕິດຕັ້ງການທົດສອບການໂຫຼດ ZeroHTTPd

ມັນເປັນສິ່ງສໍາຄັນທີ່ໃນເວລາທີ່ແລ່ນການທົດສອບ, ອົງປະກອບທັງຫມົດບໍ່ໄດ້ດໍາເນີນການຢູ່ໃນເຄື່ອງດຽວກັນ. ໃນ​ກໍ​ລະ​ນີ​ນີ້​, OS ມີ​ການ​ກໍາ​ນົດ​ເວ​ລາ​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ການ​ເປັນ​ອົງ​ປະ​ກອບ​ທີ່​ແຂ່ງ​ຂັນ​ສໍາ​ລັບ CPU​. ການວັດຜົນຂອງລະບົບປະຕິບັດການຂອງແຕ່ລະສະຖາປັດຕະຍະກໍາເຊີຟເວີທີ່ເລືອກແມ່ນຫນຶ່ງໃນເປົ້າຫມາຍທີ່ສໍາຄັນທີ່ສຸດຂອງບົດຝຶກຫັດນີ້. ການເພີ່ມຕົວແປເພີ່ມເຕີມຈະກາຍເປັນອັນຕະລາຍຕໍ່ຂະບວນການ. ດັ່ງນັ້ນ, ການຕັ້ງຄ່າໃນຮູບຂ້າງເທິງນີ້ເຮັດວຽກທີ່ດີທີ່ສຸດ.

ແຕ່ລະເຄື່ອງແມ່ຂ່າຍເຫຼົ່ານີ້ເຮັດຫຍັງ?

• load.unixism.net: ນີ້ແມ່ນບ່ອນທີ່ພວກເຮົາດໍາເນີນການ ab, Apache Benchmark utility. ມັນສ້າງການໂຫຼດທີ່ຈໍາເປັນເພື່ອທົດສອບສະຖາປັດຕະຍະກໍາຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ.
• nginx.unixism.net: ບາງຄັ້ງພວກເຮົາຕ້ອງການດໍາເນີນການຫຼາຍກວ່າຫນຶ່ງຕົວຢ່າງຂອງໂຄງການເຊີຟເວີ. ເພື່ອເຮັດສິ່ງນີ້, ເຄື່ອງແມ່ຂ່າຍ Nginx ທີ່ມີການຕັ້ງຄ່າທີ່ເຫມາະສົມເຮັດວຽກເປັນຕົວດຸ່ນດ່ຽງການໂຫຼດມາຈາກ ab ກັບຂະບວນການຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຮົາ.
• zerohttpd.unixism.net: ນີ້ພວກເຮົາດໍາເນີນໂຄງການເຊີຟເວີຂອງພວກເຮົາຢູ່ໃນເຈັດສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນ, ຫນຶ່ງໃນເວລາດຽວ.
• redis.unixism.net: ເຊີບເວີນີ້ແລ່ນ Redis daemon, ບ່ອນທີ່ບັນທຶກການເຂົ້າປື້ມບັນທຶກແຂກ ແລະເຄົາເຕີຜູ້ເຂົ້າຊົມຖືກເກັບໄວ້.

ເຊີບເວີທັງໝົດເຮັດວຽກຢູ່ໃນຫຼັກຂອງໂປເຊດເຊີດຽວກັນ. ແນວຄວາມຄິດແມ່ນເພື່ອປະເມີນປະສິດທິພາບສູງສຸດຂອງແຕ່ລະສະຖາປັດຕະຍະກໍາ. ເນື່ອງຈາກທຸກໂປຣແກຣມເຊີບເວີຖືກທົດສອບຢູ່ໃນຮາດແວດຽວກັນ, ນີ້ແມ່ນພື້ນຖານສໍາລັບການປຽບທຽບ. ການຕິດຕັ້ງການທົດສອບຂອງຂ້ອຍປະກອບດ້ວຍເຊີບເວີ virtual ທີ່ເຊົ່າຈາກ Digital Ocean.

ພວກເຮົາກໍາລັງວັດແທກຫຍັງ?

ທ່ານສາມາດວັດແທກຕົວຊີ້ວັດທີ່ແຕກຕ່າງກັນ. ພວກເຮົາປະເມີນການປະຕິບັດຂອງແຕ່ລະສະຖາປັດຕະຍະກໍາໃນການຕັ້ງຄ່າທີ່ກໍານົດໄວ້ໂດຍການໂຫຼດເຄື່ອງແມ່ຂ່າຍທີ່ມີຄໍາຮ້ອງຂໍໃນລະດັບຄວາມຂະຫນານທີ່ແຕກຕ່າງກັນ: ການໂຫຼດເພີ່ມຂຶ້ນຈາກ 20 ຫາ 15 ຜູ້ໃຊ້ພ້ອມກັນ.

ຜົນການທົດສອບ

ຕາຕະລາງຕໍ່ໄປນີ້ສະແດງໃຫ້ເຫັນການປະຕິບັດຂອງເຄື່ອງແມ່ຂ່າຍໃນສະຖາປັດຕະຍະກໍາທີ່ແຕກຕ່າງກັນໃນລະດັບຄວາມຂະຫນານທີ່ແຕກຕ່າງກັນ. ແກນ y ແມ່ນຈໍານວນການຮ້ອງຂໍຕໍ່ວິນາທີ, ແກນ x ແມ່ນການເຊື່ອມຕໍ່ຂະຫນານ.

ຂ້າງລຸ່ມນີ້ແມ່ນຕາຕະລາງທີ່ມີຜົນໄດ້ຮັບ.

ການຮ້ອງຂໍຕໍ່ວິນາທີ

ຂະຫນານ
ຊ້ຳ
ສ້ອມ
ທາງສ່ວນຫນ້າຂອງສ້ອມ
ການຖ່າຍທອດ
pre-streaming
poll
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

10
-
-
ການແຜ່ກະຈາຍໃຫຍ່
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

ຈາກກາຟແລະຕາຕະລາງສາມາດເຫັນໄດ້ວ່າຂ້າງເທິງ 8000 ຄໍາຮ້ອງຂໍພ້ອມໆກັນພວກເຮົາມີພຽງແຕ່ສອງຜູ້ນທີ່ຍັງເຫຼືອ: pre-fork ແລະ epoll. ເມື່ອການໂຫຼດເພີ່ມຂຶ້ນ, ເຊີບເວີທີ່ອີງໃສ່ແບບສຳຫຼວດຈະເຮັດວຽກຮ້າຍແຮງກວ່າການຖ່າຍທອດ. ສະຖາປັດຕະຍະກໍາຂອງ thread-pre-creation ເປັນຄູ່ແຂ່ງທີ່ສົມຄວນທີ່ຈະ epoll, ເປັນຫຼັກຖານວ່າ Linux kernel ຈັດຕາຕະລາງຈໍານວນຫລາຍຂອງກະທູ້ແນວໃດ.

ລະຫັດແຫຼ່ງ ZeroHTTPd

ລະຫັດແຫຼ່ງ ZeroHTTPd ທີ່ນີ້. ມີໄດເລກະທໍລີແຍກຕ່າງຫາກສໍາລັບແຕ່ລະສະຖາປັດຕະຍະກໍາ.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking │ ├── main.c ├── ├── 04_ thread. 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ├── Makefile ├── ສາທາລະນະ │ ─ ├── .png └── ແມ່ແບບ └── ປື້ມບັນທຶກແຂກ └── index.html

ນອກເຫນືອຈາກເຈັດໄດເລກະທໍລີສໍາລັບສະຖາປັດຕະຍະກໍາທັງຫມົດ, ຍັງມີອີກສອງໃນໄດເລກະທໍລີລະດັບສູງສຸດ: ສາທາລະນະແລະແມ່ແບບ. ທໍາອິດມີໄຟລ໌ index.html ແລະຮູບພາບຈາກຫນ້າຈໍທໍາອິດ. ເຈົ້າສາມາດວາງໄຟລ໌ ແລະໂຟນເດີ້ອື່ນໆໃສ່ບ່ອນນັ້ນໄດ້, ແລະ ZeroHTTPd ຄວນໃຫ້ບໍລິການໄຟລ໌ຄົງທີ່ເຫຼົ່ານັ້ນໂດຍບໍ່ມີບັນຫາໃດໆ. ຖ້າເສັ້ນທາງໃນຕົວທ່ອງເວັບກົງກັບເສັ້ນທາງໃນໂຟນເດີສາທາລະນະ, ຫຼັງຈາກນັ້ນ ZeroHTTPd ຊອກຫາໄຟລ໌ index.html ໃນໄດເລກະທໍລີນີ້. ເນື້ອໃນຂອງປຶ້ມທຶກຜູ້ເຂົ້າແມ່ນຖືກສ້າງຂຶ້ນແບບເຄື່ອນໄຫວ. ມັນມີພຽງແຕ່ຫນ້າທໍາອິດ, ແລະເນື້ອໃນຂອງມັນແມ່ນອີງໃສ່ໄຟລ໌ 'templates/guestbook/index.html'. ZeroHTTPd ໄດ້ຢ່າງງ່າຍດາຍເພີ່ມຫນ້າແບບເຄື່ອນໄຫວສໍາລັບການຂະຫຍາຍ. ແນວຄວາມຄິດແມ່ນວ່າຜູ້ໃຊ້ສາມາດເພີ່ມແມ່ແບບໃສ່ໄດເລກະທໍລີນີ້ແລະຂະຫຍາຍ ZeroHTTPd ຕາມຄວາມຕ້ອງການ.

ເພື່ອສ້າງເຄື່ອງແມ່ຂ່າຍທັງຫມົດເຈັດ, ດໍາເນີນການ make all ຈາກໄດເລກະທໍລີລະດັບສູງສຸດ - ແລະການກໍ່ສ້າງທັງຫມົດຈະປາກົດຢູ່ໃນໄດເລກະທໍລີນີ້. ໄຟລ໌ທີ່ປະຕິບັດໄດ້ຊອກຫາລາຍຊື່ສາທາລະນະແລະແມ່ແບບໃນໄດເລກະທໍລີທີ່ພວກມັນຖືກເປີດຕົວ.

Linux API

ທ່ານບໍ່ຈໍາເປັນຕ້ອງມີຄວາມເຂົ້າໃຈດີໃນ Linux API ເພື່ອເຂົ້າໃຈຂໍ້ມູນໃນຊຸດບົດຄວາມນີ້. ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າແນະນໍາໃຫ້ອ່ານເພີ່ມເຕີມກ່ຽວກັບຫົວຂໍ້ນີ້; ມີຫຼາຍແຫຼ່ງອ້າງອີງໃນອິນເຕີເນັດ. ເຖິງແມ່ນວ່າພວກເຮົາຈະສໍາຜັດກັບຫຼາຍປະເພດຂອງ Linux APIs, ຈຸດສຸມຂອງພວກເຮົາຈະເປັນຕົ້ນຕໍກ່ຽວກັບຂະບວນການ, ກະທູ້, ເຫດການ, ແລະ stack ເຄືອຂ່າຍ. ນອກເຫນືອຈາກປຶ້ມແລະບົດຄວາມກ່ຽວກັບ Linux API, ຂ້າພະເຈົ້າຍັງແນະນໍາໃຫ້ອ່ານ mana ສໍາລັບການໂທລະບົບແລະຫນ້າທີ່ຫ້ອງສະຫມຸດທີ່ໃຊ້.

ປະສິດທິພາບແລະການຂະຫຍາຍ

ຫມາຍເຫດຫນຶ່ງກ່ຽວກັບການປະຕິບັດແລະການຂະຫຍາຍ. ໃນທາງທິດສະດີ, ບໍ່ມີການເຊື່ອມຕໍ່ລະຫວ່າງພວກເຂົາ. ທ່ານສາມາດມີບໍລິການເວັບທີ່ເຮັດວຽກໄດ້ດີຫຼາຍ, ທີ່ມີເວລາຕອບສະຫນອງສອງສາມມິນລິວິນາທີ, ແຕ່ມັນບໍ່ໄດ້ຂະຫນາດທັງຫມົດ. ເຊັ່ນດຽວກັນ, ອາດຈະມີຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ທີ່ປະຕິບັດບໍ່ດີທີ່ໃຊ້ເວລາສອງສາມວິນາທີເພື່ອຕອບສະຫນອງ, ແຕ່ມັນຂະຫຍາຍໄດ້ຫຼາຍສິບເພື່ອຈັດການກັບຜູ້ໃຊ້ພ້ອມກັນຫຼາຍສິບພັນຄົນ. ຢ່າງໃດກໍ່ຕາມ, ການປະສົມປະສານຂອງປະສິດທິພາບສູງແລະການຂະຫຍາຍຂະຫນາດແມ່ນການປະສົມປະສານທີ່ມີປະສິດທິພາບຫຼາຍ. ຄໍາຮ້ອງສະຫມັກທີ່ມີປະສິດຕິພາບສູງໂດຍທົ່ວໄປແລ້ວຈະໃຊ້ຊັບພະຍາກອນຢ່າງບໍ່ຢຸດຢັ້ງແລະດັ່ງນັ້ນຈຶ່ງໃຫ້ບໍລິການຜູ້ໃຊ້ທີ່ມີປະສິດຕິພາບຫຼາຍຂື້ນຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ, ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍ.

ວຽກ CPU ແລະ I/O

ສຸດທ້າຍ, ໃນຄອມພິວເຕີ້ມີສອງປະເພດວຽກທີ່ເປັນໄປໄດ້: ສໍາລັບ I/O ແລະ CPU. ການຮັບຄໍາຮ້ອງຂໍຜ່ານອິນເຕີເນັດ (ເຄືອຂ່າຍ I/O), ການບໍລິການໄຟລ໌ (ເຄືອຂ່າຍແລະແຜ່ນ I/O), ການສື່ສານກັບຖານຂໍ້ມູນ (ເຄືອຂ່າຍແລະແຜ່ນ I/O) ແມ່ນກິດຈະກໍາ I/O ທັງຫມົດ. ບາງແບບສອບຖາມຖານຂໍ້ມູນສາມາດເປັນ CPU ທີ່ເຂັ້ມຂຸ້ນເລັກນ້ອຍ (ການຈັດລຽງ, ສະເລ່ຍເປັນລ້ານຜົນໄດ້ຮັບ, ແລະອື່ນໆ). ຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌ສ່ວນໃຫຍ່ຖືກຈໍາກັດໂດຍ I/O ສູງສຸດທີ່ເປັນໄປໄດ້, ແລະໂປເຊດເຊີບໍ່ຄ່ອຍຈະຖືກນໍາໃຊ້ຢ່າງເຕັມທີ່. ເມື່ອທ່ານເຫັນວ່າບາງວຽກ I/O ກໍາລັງໃຊ້ CPU ຫຼາຍ, ມັນອາດຈະເປັນສັນຍານຂອງສະຖາປັດຕະຍະກໍາຂອງແອັບພລິເຄຊັນທີ່ບໍ່ດີ. ນີ້ສາມາດຫມາຍຄວາມວ່າຊັບພະຍາກອນ CPU ໄດ້ຖືກເສຍໄປໃນການຈັດການຂະບວນການແລະການປ່ຽນສະພາບການ - ແລະນີ້ບໍ່ແມ່ນຜົນປະໂຫຍດທັງຫມົດ. ຖ້າ​ຫາກ​ວ່າ​ທ່ານ​ກໍາ​ລັງ​ເຮັດ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ເຊັ່ນ​: ການ​ປຸງ​ແຕ່ງ​ຮູບ​ພາບ​, ການ​ປ່ຽນ​ໄຟລ​໌​ສຽງ​, ຫຼື​ການ​ຮຽນ​ຮູ້​ເຄື່ອງ​, ຫຼັງ​ຈາກ​ນັ້ນ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕ້ອງ​ການ​ຊັບ​ພະ​ຍາ​ກອນ CPU ທີ່​ມີ​ອໍາ​ນາດ​. ແຕ່ສໍາລັບຄໍາຮ້ອງສະຫມັກສ່ວນໃຫຍ່, ນີ້ບໍ່ແມ່ນກໍລະນີ.

ສຶກສາເພີ່ມເຕີມກ່ຽວກັບສະຖາປັດຕະຍະກຳເຊີບເວີ

1. ພາກທີ I: ສະຖາປັດຕະຍະກໍາແບບຊ້ຳໆ
2. ພາກທີ II. ເຄື່ອງແມ່ຂ່າຍຂອງສ້ອມ
3. ພາກທີ III. ເຊີບເວີລ່ວງໜ້າ
4. ພາກທີ IV. ເຊີບເວີທີ່ມີກະທູ້ຂອງການປະຕິບັດ
5. ພາກທີ V. ເຊີບເວີກ່ອນກະທູ້
6. ພາກທີ VI. ສະຖາປັດຕະຍະກໍາທີ່ອີງໃສ່ Poll
7. ພາກທີ VII. ສະຖາປັດຕະຍະກຳທີ່ອີງໃສ່ epol

ແຫຼ່ງຂໍ້ມູນ: www.habr.com