SRE: ການວິເຄາະປະສິດທິພາບ. ວິທີການຕິດຕັ້ງໂດຍໃຊ້ເຄື່ອງແມ່ຂ່າຍເວັບງ່າຍໆໃນ Go

ການວິເຄາະປະສິດທິພາບແລະການປັບແຕ່ງເປັນເຄື່ອງມືທີ່ມີປະສິດທິພາບໃນການກວດສອບການປະຕິບັດຕາມການປະຕິບັດສໍາລັບລູກຄ້າ.

ການວິເຄາະປະສິດທິພາບສາມາດຖືກນໍາໃຊ້ເພື່ອກວດກາເບິ່ງຂໍ້ບົກພ່ອງໃນໂຄງການໂດຍການນໍາໃຊ້ວິທີການວິທະຍາສາດໃນການທົດລອງການປັບແຕ່ງການທົດລອງ. ບົດຄວາມນີ້ກໍານົດວິທີການທົ່ວໄປໃນການວິເຄາະປະສິດທິພາບແລະການປັບແຕ່ງ, ການນໍາໃຊ້ Go webserver ເປັນຕົວຢ່າງ.

Go ແມ່ນດີໂດຍສະເພາະຢູ່ທີ່ນີ້ເພາະວ່າມັນມີເຄື່ອງມືສ້າງໂປຣໄຟລ໌ pprof ໃນ​ຫ້ອງ​ສະ​ຫມຸດ​ມາດ​ຕະ​ຖານ​.

ຍຸດທະສາດ

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

• ພວກເຮົາກໍານົດຂອບເຂດການເພີ່ມປະສິດທິພາບ (ຄວາມຕ້ອງການ);
• ພວກເຮົາຄິດໄລ່ການໂຫຼດການເຮັດທຸລະກໍາສໍາລັບລະບົບ;
• ພວກເຮົາປະຕິບັດການທົດສອບ (ສ້າງຂໍ້ມູນ);
• ພວກເຮົາສັງເກດເຫັນ;
• ພວກເຮົາວິເຄາະ - ມີຄວາມຕ້ອງການທັງຫມົດບໍ?
• ພວກເຮົາຕັ້ງມັນຂຶ້ນທາງວິທະຍາສາດ, ເຮັດໃຫ້ສົມມຸດຕິຖານ;
• ພວກເຮົາດໍາເນີນການທົດລອງເພື່ອທົດສອບສົມມຸດຕິຖານນີ້.

ສະຖາປັດຕະຍະກໍາ HTTP Server ງ່າຍດາຍ

ສໍາລັບບົດຄວາມນີ້ພວກເຮົາຈະໃຊ້ເຄື່ອງແມ່ຂ່າຍ HTTP ຂະຫນາດນ້ອຍໃນ Golang. ລະຫັດທັງໝົດຈາກບົດຄວາມນີ້ສາມາດພົບໄດ້ ທີ່ນີ້.

ຄໍາຮ້ອງສະຫມັກທີ່ຖືກວິເຄາະແມ່ນເຄື່ອງແມ່ຂ່າຍ HTTP ທີ່ສໍາຫຼວດ Postgresql ສໍາລັບແຕ່ລະຄໍາຮ້ອງຂໍ. ນອກຈາກນັ້ນ, ມີ Prometheus, node_exporter ແລະ Grafana ສໍາລັບການເກັບກໍາແລະສະແດງຄໍາຮ້ອງສະຫມັກແລະລະບົບ metrics.

ເພື່ອຄວາມງ່າຍ, ພວກເຮົາພິຈາລະນາວ່າສໍາລັບການປັບຂະຫນາດຕາມແນວນອນ (ແລະການຄິດໄລ່ງ່າຍ) ແຕ່ລະບໍລິການແລະຖານຂໍ້ມູນຖືກນໍາໄປໃຊ້ຮ່ວມກັນ:

ການກໍານົດເປົ້າຫມາຍ

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

В Google SRE Book ວິທີການເລືອກແລະການສ້າງແບບຈໍາລອງໄດ້ຖືກປຶກສາຫາລືຢ່າງລະອຽດ. ໃຫ້ເຮັດແບບດຽວກັນແລະສ້າງແບບຈໍາລອງ:

• Latency: 99% ຂອງການຮ້ອງຂໍຄວນຈະສໍາເລັດໃນຫນ້ອຍກວ່າ 60ms;
• ຄ່າໃຊ້ຈ່າຍ: ການບໍລິການຄວນໃຊ້ຈໍານວນເງິນຕໍາ່ສຸດທີ່ພວກເຮົາຄິດວ່າເປັນໄປໄດ້ຢ່າງສົມເຫດສົມຜົນ. ເພື່ອເຮັດສິ່ງນີ້, ພວກເຮົາເພີ່ມການສົ່ງຜ່ານ;
• ການວາງແຜນຄວາມອາດສາມາດ: ຮຽກຮ້ອງໃຫ້ມີຄວາມເຂົ້າໃຈແລະເອກະສານຈໍານວນຕົວຢ່າງຂອງແອັບພລິເຄຊັນທີ່ຈະຕ້ອງດໍາເນີນການ, ລວມທັງການທໍາງານຂອງຂະຫນາດໂດຍລວມ, ແລະຈໍານວນຕົວຢ່າງທີ່ຕ້ອງການເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການເບື້ອງຕົ້ນແລະການສະຫນອງ. ການຊໍ້າຊ້ອນ n+1.

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

ການຕັ້ງຄ່າສະພາບແວດລ້ອມການທົດສອບ

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

ການໂຫຼດທຸລະກໍາ

ສະພາບແວດລ້ອມນີ້ໃຊ້ ຜັກສະຫລັດ ເພື່ອສ້າງອັດຕາການຮ້ອງຂໍ HTTP ແບບກໍານົດເອງຈົນກ່ວາຢຸດເຊົາ:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

ການສັງເກດ

ການໂຫຼດທຸລະກຳຈະຖືກນຳໃຊ້ໃນເວລາແລ່ນ. ນອກເຫນືອໄປຈາກຄໍາຮ້ອງສະຫມັກ (ຈໍານວນການຮ້ອງຂໍ, latency ຕອບສະຫນອງ) ແລະລະບົບປະຕິບັດງານ (ຫນ່ວຍຄວາມຈໍາ, CPU, IOPS) metrics, ຄໍາຮ້ອງສະຫມັກ profileing ຈະໄດ້ຮັບການດໍາເນີນການເພື່ອເຂົ້າໃຈບ່ອນທີ່ມັນມີບັນຫາແລະວິທີການໃຊ້ເວລາ CPU.

ການສ້າງໂປຣໄຟລ໌

Profiling ແມ່ນປະເພດຂອງການວັດແທກທີ່ຊ່ວຍໃຫ້ທ່ານເຫັນບ່ອນທີ່ເວລາ CPU ໄປໃນເວລາທີ່ແອັບພລິເຄຊັນກໍາລັງເຮັດວຽກ. ມັນຊ່ວຍໃຫ້ທ່ານສາມາດກໍານົດໄດ້ຢ່າງແທ້ຈິງວ່າບ່ອນໃດແລະເວລາຂອງໂປເຊດເຊີໃຊ້ເວລາຫຼາຍປານໃດ:

ຂໍ້ມູນນີ້ສາມາດຖືກນໍາໃຊ້ໃນລະຫວ່າງການວິເຄາະເພື່ອໃຫ້ມີຄວາມເຂົ້າໃຈກ່ຽວກັບ CPU ທີ່ເສຍເວລາແລະການເຮັດວຽກທີ່ບໍ່ຈໍາເປັນທີ່ຖືກປະຕິບັດ. Go (pprof) ສາມາດສ້າງໂປຣໄຟລ໌ແລະສະແດງພາບໃຫ້ເຂົາເຈົ້າເປັນກາຟໄຟໂດຍໃຊ້ຊຸດມາດຕະຖານຂອງເຄື່ອງມື. ຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບການນໍາໃຊ້ແລະຄູ່ມືການຕິດຕັ້ງຂອງພວກເຂົາຕໍ່ມາໃນບົດຄວາມ.

ການ​ປະ​ຕິ​ບັດ​, ການ​ສັງ​ເກດ​ການ​, ການ​ວິ​ເຄາະ​.

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

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

ເອົາໃຈໃສ່ກັບສອງກາຟເທິງ. ເບື້ອງຊ້າຍເທິງສະແດງໃຫ້ເຫັນວ່າຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາດໍາເນີນການ 50 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ (ມັນຄິດ) ແລະເບື້ອງຂວາເທິງສະແດງໃຫ້ເຫັນໄລຍະເວລາຂອງແຕ່ລະຄໍາຮ້ອງຂໍ. ທັງສອງຕົວກໍານົດການຊ່ວຍໃຫ້ພວກເຮົາເບິ່ງແລະວິເຄາະວ່າພວກເຮົາຢູ່ໃນຂອບເຂດການປະຕິບັດຂອງພວກເຮົາຫຼືບໍ່. ເສັ້ນສີແດງຢູ່ໃນເສັ້ນສະແດງ HTTP Request Latency ສະແດງ SLO ທີ່ 60ms. ເສັ້ນສະແດງວ່າພວກເຮົາຢູ່ຕໍ່າກວ່າເວລາຕອບສະຫນອງສູງສຸດຂອງພວກເຮົາ.

ໃຫ້ເບິ່ງດ້ານຄ່າໃຊ້ຈ່າຍ:

10000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ / 50 ຄໍາຮ້ອງຂໍຕໍ່ເຄື່ອງແມ່ຂ່າຍ = 200 ເຄື່ອງແມ່ຂ່າຍ + 1

ພວກເຮົາຍັງສາມາດປັບປຸງຕົວເລກນີ້.

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

ສິ່ງທີ່ຫນ້າສົນໃຈຫຼາຍເລີ່ມເກີດຂື້ນເມື່ອການໂຫຼດໄດ້ເຖິງ 500 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ:

ອີກເທື່ອຫນຶ່ງ, ໃນກາຟຊ້າຍເທິງທ່ານສາມາດເບິ່ງວ່າຄໍາຮ້ອງສະຫມັກກໍາລັງບັນທຶກການໂຫຼດປົກກະຕິ. ຖ້າບໍ່ແມ່ນກໍລະນີ, ມີບັນຫາຢູ່ໃນເຄື່ອງແມ່ຂ່າຍທີ່ແອັບພລິເຄຊັນກໍາລັງແລ່ນຢູ່. ເສັ້ນສະແດງການຕອບສະ ໜອງ ທີ່ຢູ່ດ້ານຂວາເທິງ, ສະແດງໃຫ້ເຫັນວ່າ 500 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີເຮັດໃຫ້ການຕອບໂຕ້ຊັກຊ້າ 25-40ms. ເປີເຊັນທີ 99 ຍັງພໍດີກັບ 60ms SLO ທີ່ເລືອກໄວ້ຂ້າງເທິງ.

ໃນແງ່ຂອງຄ່າໃຊ້ຈ່າຍ:

10000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ / 500 ຄໍາຮ້ອງຂໍຕໍ່ເຄື່ອງແມ່ຂ່າຍ = 20 ເຄື່ອງແມ່ຂ່າຍ + 1

ທຸກສິ່ງທຸກຢ່າງຍັງສາມາດປັບປຸງໄດ້.

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

ການເປີດຕົວທີ່ຍິ່ງໃຫຍ່! ຄໍາຮ້ອງສະຫມັກສະແດງໃຫ້ເຫັນວ່າມັນດໍາເນີນການ 1000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ, ແຕ່ຂອບເຂດຈໍາກັດ latency ໄດ້ຖືກລະເມີດໂດຍ SLO. ນີ້ສາມາດເຫັນໄດ້ໃນເສັ້ນ p99 ໃນເສັ້ນກຣາຟຂວາເທິງ. ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າເສັ້ນ p100 ແມ່ນສູງກວ່າຫຼາຍ, ຄວາມລ່າຊ້າທີ່ແທ້ຈິງແມ່ນສູງກວ່າລະດັບສູງສຸດຂອງ 60ms. ໃຫ້ພວກເຮົາເຂົ້າໄປໃນ profileing ເພື່ອຊອກຫາສິ່ງທີ່ຄໍາຮ້ອງສະຫມັກເຮັດໄດ້.

ການສ້າງໂປຣໄຟລ໌

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

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ຜົນໄດ້ຮັບສາມາດສະແດງໄດ້ເຊັ່ນນີ້:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

ເສັ້ນສະແດງສະແດງວ່າແອັບພລິເຄຊັນໃຊ້ເວລາ CPU ຢູ່ໃສ ແລະເທົ່າໃດ. ຈາກຄໍາອະທິບາຍຈາກ Brendan Gregg:

ແກນ X ແມ່ນປະຊາກອນຂໍ້ມູນ stack, ຈັດຮຽງຕາມຕົວອັກສອນ (ນີ້ບໍ່ແມ່ນເວລາ), ແກນ Y ສະແດງໃຫ້ເຫັນຄວາມເລິກຂອງ stack, ນັບຈາກສູນຢູ່ [ເທິງ]. ແຕ່ລະສີ່ຫລ່ຽມເປັນກອບ stack. ຂອບກວ້າງຂຶ້ນ, ມັນມັກຈະມີຢູ່ໃນ stacks ຫຼາຍ. ສິ່ງທີ່ຢູ່ເທິງສຸດແລ່ນຢູ່ໃນ CPU, ແລະສິ່ງທີ່ຢູ່ຂ້າງລຸ່ມນີ້ແມ່ນອົງປະກອບຂອງເດັກນ້ອຍ. ສີປົກກະຕິແລ້ວບໍ່ມີຄວາມ ໝາຍ ຫຍັງ, ແຕ່ຖືກເລືອກແບບສຸ່ມເພື່ອແຍກຄວາມແຕກຕ່າງຂອງກອບ.

ການວິເຄາະ - hypothesis

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

ປະຕິບັດຕາມຄໍາແນະນໍາຂອງ Brendan Gregg, ພວກເຮົາຈະອ່ານຕາຕະລາງຈາກເທິງລົງລຸ່ມ. ແຕ່ລະເສັ້ນສະແດງກອບ stack (ການເອີ້ນຟັງຊັນ). ເສັ້ນທໍາອິດແມ່ນຈຸດເຂົ້າໄປໃນໂຄງການ, ພໍ່ແມ່ຂອງການໂທອື່ນໆທັງຫມົດ (ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ການໂທອື່ນໆທັງຫມົດຈະມີມັນຢູ່ໃນ stack ຂອງເຂົາເຈົ້າ). ແຖວຕໍ່ໄປແມ່ນແຕກຕ່າງກັນແລ້ວ:

ຖ້າທ່ານວາງຕົວກະພິບໃສ່ຊື່ຂອງຟັງຊັນໃນກາຟ, ເວລາທັງໝົດທີ່ມັນຢູ່ໃນ stack ໃນລະຫວ່າງການດີບັກຈະຖືກສະແດງ. ຟັງຊັນ HTTPServe ຢູ່ທີ່ນັ້ນ 65% ຂອງເວລາ, ຟັງຊັນເວລາແລ່ນອື່ນໆ runtime.mcall, mstart и gc, ໄດ້ໃຊ້ເວລາເຖິງສ່ວນທີ່ເຫຼືອຂອງເວລາ. ຄວາມຈິງທີ່ມ່ວນ: 5% ຂອງເວລາທັງຫມົດແມ່ນໃຊ້ໃນການສອບຖາມ DNS:

ທີ່ຢູ່ທີ່ໂຄງການຊອກຫາເປັນຂອງ Postgresql. ໃຫ້ຄລິກໃສ່ FindByAge:

ຫນ້າສົນໃຈ, ໂຄງການສະແດງໃຫ້ເຫັນວ່າ, ໃນຫຼັກການ, ມີສາມແຫຼ່ງຕົ້ນຕໍທີ່ເພີ່ມຄວາມລ່າຊ້າ: ການເປີດແລະປິດການເຊື່ອມຕໍ່, ການຮ້ອງຂໍຂໍ້ມູນແລະການເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ. ເສັ້ນສະແດງສະແດງໃຫ້ເຫັນວ່າການຮ້ອງຂໍ DNS, ເປີດແລະປິດການເຊື່ອມຕໍ່ໃຊ້ເວລາປະມານ 13% ຂອງເວລາປະຕິບັດທັງຫມົດ.

ສົມມຸດຕິຖານ: ການນໍາໃຊ້ການເຊື່ອມຕໍ່ຄືນໃຫມ່ໂດຍໃຊ້ການລວມກັນຄວນຫຼຸດຜ່ອນເວລາຂອງຄໍາຮ້ອງຂໍ HTTP ດຽວ, ອະນຸຍາດໃຫ້ຜ່ານທີ່ສູງຂຶ້ນແລະ latency ຕ່ໍາ..

ການ​ຕັ້ງ​ຄ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ - ການ​ທົດ​ລອງ​

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

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

ການ​ປະ​ຕິ​ບັດ​, ການ​ສັງ​ເກດ​ການ​, ການ​ວິ​ເຄາະ​

ຫຼັງ​ຈາກ​ການ​ເລີ່ມ​ຕົ້ນ​ການ​ທົດ​ສອບ​ກັບ 1000 ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕໍ່​ວິ​ນາ​ທີ​, ມັນ​ເປັນ​ທີ່​ຈະ​ແຈ້ງ​ວ່າ​ລະ​ດັບ​ການ latency ຂອງ p99 ໄດ້​ກັບ​ຄືນ​ໄປ​ບ່ອນ​ປົກ​ກະ​ຕິ​ດ້ວຍ SLO ຂອງ 60ms​!

ຄ່າໃຊ້ຈ່າຍແມ່ນຫຍັງ?

10000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ / 1000 ຄໍາຮ້ອງຂໍຕໍ່ເຄື່ອງແມ່ຂ່າຍ = 10 ເຄື່ອງແມ່ຂ່າຍ + 1

ໃຫ້ເຮັດມັນດີກວ່າ!

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

ການໂຫຼດສອງເທົ່າສະແດງໃຫ້ເຫັນເຖິງສິ່ງດຽວກັນ, ເສັ້ນສະແດງເທິງຊ້າຍສະແດງໃຫ້ເຫັນວ່າແອັບພລິເຄຊັນຈັດການການຮ້ອງຂໍ 2000 ຕໍ່ວິນາທີ, p100 ຕ່ໍາກວ່າ 60ms, p99 ພໍໃຈ SLO.

ໃນແງ່ຂອງຄ່າໃຊ້ຈ່າຍ:

10000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ / 2000 ຄໍາຮ້ອງຂໍຕໍ່ເຄື່ອງແມ່ຂ່າຍ = 5 ເຄື່ອງແມ່ຂ່າຍ + 1

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

ທີ່ນີ້ແອັບພລິເຄຊັນສາມາດປະມວນຜົນ 3000 ຄໍາຮ້ອງຂໍທີ່ມີ p99 latency ຫນ້ອຍກວ່າ 60ms. SLO ບໍ່ໄດ້ຖືກລະເມີດ, ແລະຄ່າໃຊ້ຈ່າຍແມ່ນຍອມຮັບດັ່ງຕໍ່ໄປນີ້:

10000 ຄໍາຮ້ອງຂໍຕໍ່ວິນາທີ / ຕໍ່ 3000 ຄໍາຮ້ອງຂໍຕໍ່ເຄື່ອງແມ່ຂ່າຍ = 4 ເຄື່ອງແມ່ຂ່າຍ + 1 (ຜູ້ຂຽນໄດ້ສະຫຼຸບ, ປະມານ ນັກແປ)

ໃຫ້ລອງວິເຄາະຮອບອື່ນ.

ການວິເຄາະ - hypothesis

ພວກ​ເຮົາ​ເກັບ​ກໍາ​ແລະ​ສະ​ແດງ​ຜົນ​ຂອງ debugging ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່ 3000 ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຕໍ່​ວິ​ນາ​ທີ​:

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

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

ການ​ຕັ້ງ​ຄ່າ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ - ການ​ທົດ​ລອງ​

ກຳລັງພະຍາຍາມຕິດຕັ້ງ MaxIdleConns ເທົ່າກັບຂະຫນາດສະນຸກເກີ (ຍັງອະທິບາຍ ທີ່ນີ້):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

ການ​ປະ​ຕິ​ບັດ​, ການ​ສັງ​ເກດ​ການ​, ການ​ວິ​ເຄາະ​

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

p99 ແມ່ນຫນ້ອຍກວ່າ 60ms ກັບ p100 ຫນ້ອຍລົງຢ່າງຫຼວງຫຼາຍ!

ການກວດສອບກາຟ flame ສະແດງໃຫ້ເຫັນວ່າການເຊື່ອມຕໍ່ແມ່ນບໍ່ສັງເກດເຫັນ! ໃຫ້ກວດເບິ່ງລາຍລະອຽດເພີ່ມເຕີມ pg(*conn).query — ພວກ​ເຮົາ​ຍັງ​ບໍ່​ໄດ້​ສັງ​ເກດ​ເຫັນ​ການ​ເຊື່ອມ​ຕໍ່​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​ຢູ່​ທີ່​ນີ້​.

ສະຫລຸບ

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

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