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

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

ກ່ອນທີ່ຂ້ອຍຈະເອົາ Alvin ເຂົ້າໄປໃນການທົດສອບ, ຂ້ອຍໄດ້ດໍາເນີນການທົດລອງຫຼາຍຢ່າງກັບ 40k queries ຕໍ່ວິນາທີ (QPS), ທັງຫມົດສະແດງໃຫ້ເຫັນ latency ຫນ້ອຍກວ່າ 10ms. ຂ້ອຍພ້ອມທີ່ຈະປະກາດວ່າຂ້ອຍບໍ່ເຫັນດີກັບຜົນໄດ້ຮັບຂອງພວກເຂົາ. ແຕ່ເບິ່ງຈົດຫມາຍສະບັບອື່ນ, ຂ້ອຍສັງເກດເຫັນສິ່ງໃຫມ່: ຂ້ອຍບໍ່ໄດ້ທົດສອບເງື່ອນໄຂທີ່ພວກເຂົາໄດ້ກ່າວມາຢ່າງແນ່ນອນ, QPS ຂອງພວກເຂົາແມ່ນຕ່ໍາກວ່າຂອງຂ້ອຍ. ຂ້າພະເຈົ້າໄດ້ທົດສອບຢູ່ທີ່ 40k QPS, ແຕ່ພວກເຂົາພຽງແຕ່ຢູ່ທີ່ 1k. ຂ້າພະເຈົ້າໄດ້ດໍາເນີນການທົດລອງອື່ນ, ເວລານີ້ດ້ວຍ QPS ຕ່ໍາ, ພຽງແຕ່ເພື່ອເອົາໃຈພວກເຂົາ.

ນັບຕັ້ງແຕ່ຂ້ອຍກໍາລັງຂຽນບລັອກກ່ຽວກັບເລື່ອງນີ້, ເຈົ້າອາດຈະຄິດແລ້ວວ່າຕົວເລກຂອງພວກເຂົາຖືກຕ້ອງ. ຂ້າພະເຈົ້າໄດ້ທົດສອບລູກຄ້າ virtual ຂອງຂ້ອຍເລື້ອຍໆ, ດ້ວຍຜົນໄດ້ຮັບດຽວກັນ: ຈໍານວນຄໍາຮ້ອງຂໍທີ່ຕໍ່າບໍ່ພຽງແຕ່ເພີ່ມຄວາມລ່າຊ້າ, ແຕ່ເພີ່ມຈໍານວນຄໍາຮ້ອງຂໍທີ່ມີ latency ຫຼາຍກວ່າ 10 ms. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຖ້າຢູ່ທີ່ 40k QPS ປະມານ 50 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີເກີນ 50 ms, ຫຼັງຈາກນັ້ນຢູ່ທີ່ 1k QPS ມີ 100 ຄໍາຮ້ອງຂໍສູງກວ່າ 50 ms ທຸກໆວິນາທີ. Paradox!

ຮັດແຄບການຄົ້ນຫາ

ໃນເວລາທີ່ປະເຊີນກັບບັນຫາ latency ໃນລະບົບການແຈກຢາຍທີ່ມີຫຼາຍອົງປະກອບ, ຂັ້ນຕອນທໍາອິດແມ່ນການສ້າງບັນຊີລາຍຊື່ສັ້ນຂອງຜູ້ຕ້ອງສົງໄສ. ຂໍໃຫ້ເຈາະເລິກເຂົ້າໄປໃນສະຖາປັດຕະຍະກໍາຂອງ Alvin ເລັກນ້ອຍ:

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

ໂທເຄືອຂ່າຍຈາກລູກຄ້າໄປຫາ Alvin.
ໂທເຄືອຂ່າຍຈາກ Alvin ໄປຫາບ່ອນເກັບຂໍ້ມູນ.
ຄົ້ນຫາໃນແຜ່ນໃນບ່ອນເກັບຂໍ້ມູນ.
ໂທເຄືອຂ່າຍຈາກຄັງຂໍ້ມູນໄປຫາ Alvin.
ໂທເຄືອຂ່າຍຈາກ Alvin ກັບລູກຄ້າ.

ໃຫ້ພະຍາຍາມຂ້າມອອກບາງຈຸດ.

ການເກັບຮັກສາຂໍ້ມູນບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບມັນ

ສິ່ງທໍາອິດທີ່ຂ້ອຍເຮັດແມ່ນປ່ຽນ Alvin ເປັນເຄື່ອງແມ່ຂ່າຍ ping-ping ທີ່ບໍ່ດໍາເນີນການຮ້ອງຂໍ. ເມື່ອມັນໄດ້ຮັບການຮ້ອງຂໍ, ມັນຈະສົ່ງຄືນຄໍາຕອບທີ່ຫວ່າງເປົ່າ. ຖ້າເວລາ latency ຫຼຸດລົງ, ແມງໄມ້ໃນ Alvin ຫຼືການປະຕິບັດຄັງຂໍ້ມູນແມ່ນບໍ່ມີຫຍັງທີ່ບໍ່ເຄີຍໄດ້ຍິນ. ໃນການທົດລອງຄັ້ງທໍາອິດພວກເຮົາໄດ້ຮັບເສັ້ນສະແດງດັ່ງຕໍ່ໄປນີ້:

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້, ບໍ່ມີການປັບປຸງໃນເວລາທີ່ໃຊ້ເຄື່ອງແມ່ຂ່າຍ ping-ping. ນີ້ຫມາຍຄວາມວ່າສາງຂໍ້ມູນບໍ່ໄດ້ເພີ່ມທະວີການ latency, ແລະບັນຊີລາຍຊື່ຂອງຜູ້ຕ້ອງສົງໄສຖືກຕັດອອກເປັນເຄິ່ງຫນຶ່ງ:

ໂທເຄືອຂ່າຍຈາກລູກຄ້າໄປຫາ Alvin.
ໂທເຄືອຂ່າຍຈາກ Alvin ກັບລູກຄ້າ.

ຍິ່ງໃຫຍ່! ບັນຊີລາຍຊື່ແມ່ນຫຼຸດລົງຢ່າງໄວວາ. ຂ້ອຍຄິດວ່າຂ້ອຍເກືອບຈະຮູ້ເຫດຜົນແລ້ວ.

ກ. ພ. ພ

ດຽວນີ້ເຖິງເວລາທີ່ຈະແນະນຳເຈົ້າໃຫ້ກັບຜູ້ຫຼິ້ນໃໝ່: ກ. ພ. ພ. ນີ້ແມ່ນຫ້ອງສະໝຸດແຫຼ່ງເປີດຈາກ Google ສໍາລັບການສື່ສານໃນຂະບວນການ CPR. ເຖິງແມ່ນວ່າ gRPC ການເພີ່ມປະສິດທິພາບທີ່ດີແລະຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງ, ນີ້ແມ່ນຄັ້ງທໍາອິດຂອງຂ້ອຍທີ່ໃຊ້ມັນຢູ່ໃນລະບົບຂະຫນາດນີ້ແລະຂ້ອຍຄາດວ່າການປະຕິບັດຂອງຂ້ອຍຈະເຫມາະສົມທີ່ສຸດ - ເວົ້າຫນ້ອຍທີ່ສຸດ.

ມີ gRPC ໃນ stack ໄດ້ເຮັດໃຫ້ເກີດຄໍາຖາມໃຫມ່: ບາງທີມັນເປັນການປະຕິບັດຂອງຂ້ອຍຫຼືຂ້ອຍເອງ gRPC ເຮັດໃຫ້ເກີດບັນຫາ latency? ເພີ່ມຜູ້ຕ້ອງສົງໄສໃໝ່ໃສ່ລາຍຊື່:

ລູກຄ້າໂທຫາຫ້ອງສະຫມຸດ gRPC
ຫ້ອງສະຫມຸດ gRPC ເຮັດໃຫ້ເຄືອຂ່າຍໂທຫາຫ້ອງສະຫມຸດຢູ່ໃນລູກຄ້າ gRPC ໃນເຊີບເວີ
ຫ້ອງສະຫມຸດ gRPC ຕິດຕໍ່ Alvin (ບໍ່ມີການດໍາເນີນງານໃນກໍລະນີຂອງເຄື່ອງແມ່ຂ່າຍຂອງ ping-pong)

ເພື່ອໃຫ້ທ່ານມີຄວາມຄິດກ່ຽວກັບສິ່ງທີ່ລະຫັດເບິ່ງຄືວ່າ, ການປະຕິບັດລູກຄ້າ / Alvin ຂອງຂ້ອຍບໍ່ແຕກຕ່າງຈາກລູກຄ້າ - ເຄື່ອງແມ່ຂ່າຍ. ຕົວຢ່າງ async.

ຫມາຍເຫດ: ບັນຊີລາຍຊື່ຂ້າງເທິງນີ້ແມ່ນງ່າຍດາຍເລັກນ້ອຍເພາະວ່າ gRPC ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະນໍາໃຊ້ຂອງທ່ານເອງ (ແມ່ແບບ?) threading ຕົວແບບ, ໃນທີ່ stack ການປະຕິບັດແມ່ນ intertwined. gRPC ແລະການຈັດຕັ້ງປະຕິບັດຂອງຜູ້ໃຊ້. ສໍາລັບ sake ຂອງຄວາມງ່າຍດາຍ, ພວກເຮົາຈະຕິດກັບຮູບແບບນີ້.

Profiling ຈະແກ້ໄຂທຸກສິ່ງທຸກຢ່າງ

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

ຂ້ອຍເອົາສີ່ໂປໄຟ: ທີ່ມີ QPS ສູງ (latency ຕ່ໍາ) ແລະກັບເຄື່ອງແມ່ຂ່າຍ ping-pong ທີ່ມີ QPS ຕ່ໍາ (latency ສູງ), ທັງຂ້າງລູກຄ້າແລະຂ້າງເຊີຟເວີ. ແລະພຽງແຕ່ໃນກໍລະນີ, ຂ້າພະເຈົ້າຍັງໄດ້ເອົາໂປໄຟໂປເຊດເຊີຕົວຢ່າງ. ເມື່ອປຽບທຽບໂປຼໄຟລ໌, ຂ້ອຍມັກຈະຊອກຫາ stack call ຜິດປົກກະຕິ. ຕົວຢ່າງ, ໃນດ້ານທີ່ບໍ່ດີທີ່ມີ latency ສູງ, ມີຫຼາຍຕົວປ່ຽນສະພາບການ (10 ເທື່ອຫຼືຫຼາຍກວ່ານັ້ນ). ແຕ່ໃນກໍລະນີຂອງຂ້ອຍ, ຈໍານວນຂອງສະຫຼັບສະພາບການແມ່ນເກືອບຄືກັນ. ໃນຄວາມຢ້ານຂອງຂ້ອຍ, ບໍ່ມີຫຍັງທີ່ສໍາຄັນຢູ່ທີ່ນັ້ນ.

ການດີບັກເພີ່ມເຕີມ

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

ຖ້າຫາກວ່າ

ຕັ້ງແຕ່ເລີ່ມຕົ້ນ, ຂ້ອຍກັງວົນກ່ຽວກັບ 50ms latency ສະເພາະ. ນີ້ແມ່ນເວລາອັນໃຫຍ່ຫຼວງຫຼາຍ. ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈວ່າຂ້ອຍຈະຕັດຊິ້ນສ່ວນອອກຈາກລະຫັດຈົນກ່ວາຂ້ອຍສາມາດຄິດໄດ້ວ່າສ່ວນໃດທີ່ເຮັດໃຫ້ເກີດຄວາມຜິດພາດນີ້. ຫຼັງຈາກນັ້ນ, ການທົດລອງທີ່ໄດ້ຜົນ.

ຕາມປົກກະຕິ, ໃນທາງຫລັງ, ມັນເບິ່ງຄືວ່າທຸກສິ່ງທຸກຢ່າງຈະແຈ້ງ. ຂ້າພະເຈົ້າໄດ້ວາງລູກຄ້າຢູ່ໃນເຄື່ອງດຽວກັນກັບ Alvin - ແລະສົ່ງຄໍາຮ້ອງຂໍໃຫ້ localhost. ແລະການເພີ່ມຂຶ້ນຂອງ latency ແມ່ນຫມົດໄປ!

ມີບາງຢ່າງຜິດພາດກັບເຄືອຂ່າຍ.

ການຮຽນຮູ້ທັກສະວິສະວະກອນເຄືອຂ່າຍ

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

ໂຊກດີ, ອິນເຕີເນັດຮັກຜູ້ທີ່ຕ້ອງການຮຽນຮູ້. ການປະສົມປະສານຂອງ ping ແລະ tracert ເບິ່ງຄືວ່າເປັນການເລີ່ມຕົ້ນທີ່ດີສໍາລັບການແກ້ໄຂບັນຫາການຂົນສົ່ງເຄືອຂ່າຍ.

ທໍາອິດ, ຂ້າພະເຈົ້າໄດ້ເປີດຕົວ PsPing ໄປຫາພອດ TCP ຂອງ Alvin. ຂ້ອຍໃຊ້ການຕັ້ງຄ່າເລີ່ມຕົ້ນ - ບໍ່ມີຫຍັງພິເສດ. ໃນຫຼາຍກວ່າຫນຶ່ງພັນ pings, ບໍ່ມີອັນໃດເກີນ 10 ms, ຍົກເວັ້ນຄັ້ງທໍາອິດສໍາລັບການອົບອຸ່ນຂຶ້ນ. ນີ້ແມ່ນກົງກັນຂ້າມກັບການເພີ່ມຂຶ້ນຂອງ latency ຂອງ 50 ms ໃນອັດຕາສ່ວນ 99th: ຢູ່ທີ່ນັ້ນ, ສໍາລັບທຸກໆ 100 ຄໍາຮ້ອງຂໍ, ພວກເຮົາຄວນຈະໄດ້ເຫັນປະມານຫນຶ່ງຄໍາຮ້ອງຂໍທີ່ມີ latency 50 ms.

ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ພະຍາຍາມ ຄວາມແນ່ນອນ: ອາດຈະມີບັນຫາຢູ່ໃນຫນຶ່ງຂອງ nodes ຕາມເສັ້ນທາງລະຫວ່າງ Alvin ແລະລູກຄ້າ. ແຕ່ຜູ້ຕິດຕາມຍັງກັບຄືນມາມືເປົ່າ.

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

ດຽວນີ້ພວກເຮົາຢູ່ໃນ OS ໃດ

gRPC ນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນ Linux, ແຕ່ສຳລັບ Windows ນີ້ແມ່ນສິ່ງທີ່ແປກປະຫຼາດ. ຂ້ອຍໄດ້ຕັດສິນໃຈດຳເນີນການທົດລອງທີ່ໄດ້ຜົນ: ຂ້ອຍໄດ້ສ້າງເຄື່ອງ virtual. Linux, ລວບລວມ Alvin ສຳລັບ Linux ແລະ ໄດ້ເປີດມັນອອກ.

ແລະນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນ: ໃນເຊີບເວີປິງປອງ Linux ບໍ່ມີຄວາມລ່າຊ້າຄືກັບໂຫນດທີ່ຄ້າຍຄືກັນ Windows, ເຖິງແມ່ນວ່າແຫຼ່ງຂໍ້ມູນແມ່ນອັນດຽວກັນ. ມັນປາກົດວ່າບັນຫາແມ່ນຢູ່ໃນການຈັດຕັ້ງປະຕິບັດ gRPC ສຳລັບ Windows.

ສູດການຄິດໄລ່ຂອງ Nagle

ຕະຫຼອດເວລານີ້ຂ້ອຍຄິດວ່າຂ້ອຍຂາດທຸງຊາດ gRPC. ດຽວນີ້ຂ້ອຍເຂົ້າໃຈວ່າມັນແມ່ນຫຍັງແທ້ໆ gRPC ທຸງຫາຍໄປ Windowsຂ້ອຍພົບຫ້ອງສະໝຸດ RPC ພາຍໃນທີ່ຂ້ອຍໝັ້ນໃຈວ່າຈະເຮັດວຽກໄດ້ດີສຳລັບທຸກທຸງທີ່ຕັ້ງໄວ້. Winsockຫຼັງຈາກນັ້ນ, ຂ້ອຍໄດ້ເພີ່ມທຸງທັງໝົດເຫຼົ່ານີ້ໃສ່ gRPC ແລະ ນຳໃຊ້ Alvin ໃສ່ Windows, ໃນເຊີບເວີປິງປອງຄົງທີ່ພາຍໃຕ້ Windows!

ເກືອບ ສຳເລັດແລ້ວ: ຂ້ອຍເລີ່ມເອົາທຸງທີ່ເພີ່ມມາອອກເທື່ອລະອັນ ຈົນກວ່າການຖົດຖອຍກັບຄືນມາເພື່ອໃຫ້ຂ້ອຍສາມາດຊີ້ບອກສາເຫດໄດ້. ມັນແມ່ນການ infamous TCP_NODELAY, ສະຫຼັບ algorithm ຂອງ Nagle.

ສູດການຄິດໄລ່ຂອງ Nagle ພະຍາຍາມຫຼຸດຜ່ອນຈໍານວນແພັກເກັດທີ່ສົ່ງຜ່ານເຄືອຂ່າຍໂດຍການຊັກຊ້າການສົ່ງຂໍ້ຄວາມຈົນກ່ວາຂະຫນາດແພັກເກັດເກີນຈໍານວນໄບຕ໌ທີ່ແນ່ນອນ. ໃນຂະນະທີ່ນີ້ອາດຈະດີສໍາລັບຜູ້ໃຊ້ໂດຍສະເລ່ຍ, ມັນເປັນການທໍາລາຍເຄື່ອງແມ່ຂ່າຍໃນເວລາທີ່ແທ້ຈິງຍ້ອນວ່າ OS ຈະຊັກຊ້າບາງຂໍ້ຄວາມ, ເຊິ່ງກໍ່ໃຫ້ເກີດຄວາມຊັກຊ້າໃນ QPS ຕ່ໍາ. U gRPC ທຸງນີ້ຖືກຕັ້ງໄວ້ໃນການຈັດຕັ້ງປະຕິບັດ Linux ສຳລັບຊັອກເກັດ TCP, ແຕ່ບໍ່ແມ່ນສຳລັບ Windowsຂ້ອຍຄືອັນນີ້ ແກ້ໄຂ.

ສະຫລຸບ

latency ສູງຂຶ້ນຢູ່ທີ່ QPS ຕໍ່າແມ່ນເກີດມາຈາກການເພີ່ມປະສິດທິພາບຂອງ OS. ໃນດ້ານຫລັງ, profileing ບໍ່ໄດ້ກວດພົບຄວາມລ່າຊ້າເພາະວ່າມັນຖືກເຮັດຢູ່ໃນໂຫມດ kernel ແທນທີ່ຈະຢູ່ໃນ ຮູບແບບຜູ້ໃຊ້. ຂ້ອຍບໍ່ຮູ້ວ່າ algorithm ຂອງ Nagle ສາມາດສັງເກດໄດ້ໂດຍຜ່ານ ETW captures, ແຕ່ມັນຫນ້າສົນໃຈ.

ສໍາລັບການທົດລອງ localhost, ມັນອາດຈະບໍ່ໄດ້ແຕະລະຫັດເຄືອຂ່າຍຕົວຈິງແລະ algorithm ຂອງ Nagle ບໍ່ໄດ້ເຂົ້າໄປໃນ, ດັ່ງນັ້ນບັນຫາ latency ຫາຍໄປເມື່ອລູກຄ້າເຂົ້າຫາ Alvin ຜ່ານ localhost.

ໃນຄັ້ງຕໍ່ໄປທີ່ທ່ານເຫັນການເພີ່ມຂື້ນຂອງ latency ເນື່ອງຈາກຈໍານວນການຮ້ອງຂໍຕໍ່ວິນາທີຫຼຸດລົງ, algorithm ຂອງ Nagle ຄວນຢູ່ໃນລາຍຊື່ຜູ້ຕ້ອງສົງໄສຂອງທ່ານ!

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