ຮົບຂອງເຄື່ອງແມ່ຂ່າຍເວັບ. ສ່ວນທີ 1 - HTTP ບໍ່ໄດ້ສໍາພັດ:

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

ການທົດສອບນີ້ແມ່ນການວັດແທກຂອງມ້າ spherical ໃນສູນຍາກາດ, ບໍ່ມີຫຍັງຫຼາຍກ່ວາຂໍ້ມູນທີ່ໄດ້ຮັບ, ແລະໃນປັດຈຸບັນພວກເຮົາບໍ່ຮູ້ວ່າຈະເຮັດແນວໃດກັບມັນ.

ວິທີການ

ລະບົບປະຕິບັດການສໍາລັບ Nginx ແລະ Apache ແມ່ນ Ubuntu 18.04 LTS, ສໍາລັບ IIS Windows Server Core 2019. ກ່ອນການທົດສອບ, ລະບົບປະຕິບັດການທັງຫມົດໄດ້ຮັບການອັບເດດຫຼ້າສຸດໃນວັນທີ 04.12.2019 ທັນວາ XNUMX.

ການທົດສອບໄດ້ຖືກປະຕິບັດສະເພາະຜ່ານ HTTP. ແຕ່ລະເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ແລ່ນຫນ້າດຽວກັນ, ເປັນແມ່ແບບ Jekyll ຟຣີຈາກ Codrops. ການເຊື່ອມຕໍ່. ແຕ່ລະເຊີບເວີໄດ້ປິດການບີບອັດ gzip.

ການທົດສອບຜ່ານແມ່ນເຮັດດ້ວຍ Httpd-tools ດ້ວຍການໂຕ້ຖຽງ:

ab -n 50000 -c 500 http://192.168.76.204:80/

ເຊີບເວີຖືກຈໍາກັດຢູ່ທີ່ 10, 5, ແລະ 1 ເປີເຊັນຂອງຫຼັກໃນ 8, 4, ແລະຫນຶ່ງຫຼັກ. ບ່ອນນັ່ງທົດສອບແມ່ນຄອມພິວເຕີທີ່ມີ 9900K@5400MHz, ຊຶ່ງຫມາຍຄວາມວ່າເຄື່ອງແມ່ຂ່າຍທີ່ໄດ້ຮັບຂອບເຂດຈໍາກັດ 10% ໄດ້ຮັບປະມານ 540MHz ຕໍ່ຫຼັກ.

ການທົດສອບ TTFB ໄດ້ຖືກປະຕິບັດໃນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍທໍາອິດ booted ແລະວັດແທກໂດຍໃຊ້ DevTools;

ຕົວທົດສອບ ແລະເຊີບເວີເວັບຢູ່ໃນໂຮດດຽວກັນ ແລະຢູ່ໃນສະວິດສະເໝືອນດຽວກັນ.

ເພື່ອປະເມີນລະບົບຍ່ອຍຂອງແຜ່ນໃນທັນທີ, ຜົນໄດ້ຮັບຂອງດັດຊະນີ ATTO ແລະ CrystalDIskMark ເພື່ອໃຫ້ມີຄວາມຄິດຂອງຂໍ້ບົກຜ່ອງ.

ຂໍ້​ມູນ​ທີ່​ໄດ້​ຮັບ​ຈາກ virtual machine ໄດ້​:

ຜົນໄດ້ຮັບ:

TTFB:

TTFB ສະເລ່ຍສໍາລັບ IIS ແມ່ນນ້ອຍທີ່ສຸດ, 0,5ms, ທຽບກັບ 1,4ms ສໍາລັບ Apache ແລະ 4ms ສໍາລັບ Nginx.

ຜ່ານ:

ທໍາອິດ, ໃຫ້ເບິ່ງວິທີການຂອງແຕ່ລະເຄື່ອງແມ່ຂ່າຍຂອງຂະຫນາດໂດຍອີງໃສ່ຈໍານວນຂອງແກນ.

ເສັ້ນສະແດງສະແດງຈໍານວນການໂທຫາຜູ້ທົດສອບກັບເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ແລະການ latency. ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າ NGINX ດໍາເນີນການ 98% ຂອງການຮ້ອງຂໍທັງຫມົດ, ສົ່ງເວັບໄຊທ໌ໃນ 20ms ຫຼືຫນ້ອຍກວ່າ. IIS, ເຊັ່ນ Apache, ສໍາເລັດ 5% ສຸດທ້າຍຂອງການໂທທັງຫມົດໃນ 76ms ແລະ 14ms, ຕາມລໍາດັບ.

ເສັ້ນສະແດງສະແດງເວລາປະມວນຜົນໂດຍສະເລ່ຍສໍາລັບການຮ້ອງຂໍຫນຶ່ງໃນລະຫວ່າງການທົດສອບຄວາມກົດດັນ.

ດັ່ງທີ່ເຈົ້າສາມາດເຫັນໄດ້ຈາກກາຟ, IIS ໄດ້ລະເບີດທັງ Apache ແລະ Nginx, ຊ້າລົງຢ່າງຫຼວງຫຼາຍພາຍໃຕ້ການໂຫຼດສູງ. 

IIS ຊັດເຈນມັກ 4 cores ຫຼາຍກວ່າ XNUMX, ສະແດງໃຫ້ເຫັນ latencies ຕ່ໍາສຸດ XNUMX, ແຕ່ຍັງບໍ່ໄດ້ສະຫນັບສະຫນູນຢ່າງແຂງແຮງຫນຶ່ງຫຼັກ.

NGINX ປັບຂະຫນາດໄດ້ດີໃນທົ່ວທຸກ 8 cores, ແລະສໍາລັບ Apache, ສະຖານະການທີ່ມີແກນດຽວເບິ່ງຄືວ່າເປັນທາງເລືອກທີ່ດີທີ່ສຸດ.

ຄວາມສາມາດໃນການຂະຫຍາຍ:

nginx:

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງການຂະຫຍາຍຂະໜາດໃນແງ່ຂອງຄວາມຖີ່ ແລະຈຳນວນຂອງແກນ. 

Nginx ບໍ່ຜ່ານການທົດສອບທີ່ມີຂອບເຂດຈໍາກັດ 1% ສໍາລັບ 4 ແລະ 1 cores ເມື່ອມັນເກີນ 2000 ຄໍາຮ້ອງຂໍ, ມັນໄດ້ຢຸດເຊົາການເຊື່ອມຕໍ່ກັບຜູ້ທົດສອບ.

Apache:

Apache, ເຊັ່ນ Nginx, ໄດ້ດໍາເນີນການ 2500 ຄໍາຮ້ອງຂໍ, ຍອມແພ້ແລະປິດການເຊື່ອມຕໍ່. Apache ລົ້ມເຫລວໃນການທົດສອບໃນ 8, 4 ແລະ 1 cores ທີ່ມີຂອບເຂດຈໍາກັດ 1%, ແຕ່ນອກຈາກນັ້ນມັນຍັງລົ້ມເຫລວໃນການທົດສອບທີ່ມີຂອບເຂດຈໍາກັດ 5% ໃນຫນຶ່ງຫຼັກ, ເຊິ່ງຮ້າຍແຮງກວ່າ Nginx.

IIS:

ໃນ​ລະ​ຫວ່າງ​ການ​ທົດ​ສອບ​, IIS ໄດ້​ສະ​ສົມ​ແຖວ​ຂະ​ຫນາດ​ໃຫຍ່​ຂອງ​ການ​ຮ້ອງ​ຂໍ​ແຕ່​ການ​ປຸງ​ແຕ່ງ​ແຕ່​ລະ​ຂອງ​ເຂົາ​ເຈົ້າ​. ປາກົດຂື້ນ, ຢູ່ນອກກ່ອງບໍ່ມີເວລາຫມົດເວລາສໍາລັບການດໍາເນີນການຮ້ອງຂໍ.

ຕາຕະລາງສະແດງໃຫ້ເຫັນເວລາທີ່ມັນໃຊ້ເວລາເພື່ອເຮັດສໍາເລັດການທົດສອບ. ການຕັ້ງຄ່າການທົດສອບທີ່ໂງ່ຢ່າງສົມບູນໄດ້ຖືກຍົກເລີກ. ແຜນວາດສະແດງໃຫ້ເຫັນວ່າ IIS ຕ້ອງການແນວໃດເມື່ອເວົ້າເຖິງຮາດແວ, ແລະ NGINX ມີຄວາມວິເສດແນວໃດ.

ຄວາມ​ສາ​ມາດ​ຂະ​ຫຍາຍ​ຕົວ​ຈາກ​ແຜ່ນ​:

nginx:

ຕອນນີ້ໃຫ້ເຮົາມາເບິ່ງການຂະຫຍາຍໃນແງ່ຂອງຄວາມຖີ່ ແລະຈໍານວນຂອງແກນ ແລະຄວາມໄວຂອງແຜ່ນ. 

ເວລານີ້ Nginx ລົ້ມເຫລວ 4 ການທົດສອບແທນທີ່ຈະສອງ.

Apache:

Apache ລົ້ມເຫລວໃນຈໍານວນການທົດສອບດຽວກັນກັບຄັ້ງທີ່ຜ່ານມາ.

IIS:

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

ມັນໄວເກີນໄປທີ່ຈະສະຫຼຸບໂດຍອີງໃສ່ການທົດສອບນີ້ພວກເຮົາຍັງບໍ່ທັນໄດ້ທົດສອບ HTTPS, ການບີບອັດແລະ HTTP/2 ດ້ວຍໃບຢັ້ງຢືນສົດຈາກ Let's Encrypt. ພວກເຮົາຈະເວົ້າກ່ຽວກັບເລື່ອງນີ້ໃນບົດຄວາມຕໍ່ໄປ.

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