การทดสอบประสิทธิภาพและการเพิ่มประสิทธิภาพ Blockchain - ตอนที่ 1
ชื่อระดับแรก
โครงร่าง
บทความนี้มีวัตถุประสงค์เพื่อแนะนำกระบวนการโครงการประสิทธิภาพที่สมบูรณ์ผ่านตัวอย่างเฉพาะ (cosmos-sdk SimApp) เนื้อหาเฉพาะแนะนำการทดสอบประสิทธิภาพบล็อกเชนที่ใช้:
1. แนวคิดพื้นฐาน
2. เครื่องมือทั่วไป
ชื่อระดับแรก
แนวคิดพื้นฐาน
การทดสอบประสิทธิภาพ Blockchain มีระเบียบวิธีไม่ต่างจากการทดสอบประสิทธิภาพแบบดั้งเดิม มีแนวคิดที่สับสนมากมายในการทดสอบประสิทธิภาพ ในที่นี้ ผมแสดงรายการแนวคิดที่อธิบายไว้ในบทความนี้เพื่อให้คำนิยาม
ชื่อเรื่องรอง
ความหมายของการทดสอบประสิทธิภาพ
การทดสอบประสิทธิภาพคือการสร้างกลยุทธ์การตรวจสอบสำหรับตัวบ่งชี้ประสิทธิภาพของระบบหรือบริการ ดำเนินการทดสอบในสถานการณ์เฉพาะ วิเคราะห์และตัดสินคอขวดของประสิทธิภาพและปรับให้เหมาะสม และสุดท้ายรับผลลัพธ์ประสิทธิภาพเพื่อประเมินว่าตัวบ่งชี้ประสิทธิภาพของระบบหรือบริการตรงตามค่าที่กำหนดไว้ล่วงหน้าหรือไม่ นี่คือคำอธิบายร่วมกับ simapp blockchain ของ cosmos-sdk
1. จำเป็นต้องชี้แจงตัวบ่งชี้ ซึ่งโดยทั่วไปหมายถึงตัวบ่งชี้ 2 ประเภท ได้แก่ ตัวบ่งชี้ทางเทคนิคและตัวบ่งชี้ทางธุรกิจ ตัวบ่งชี้ทางเทคนิคโดยทั่วไปคือ TPS เวลาตอบสนอง และการใช้ทรัพยากร สอดคล้องกับ blockchain โดยทั่วไปหมายถึงจำนวนธุรกรรมที่สามารถดำเนินการต่อวินาที? เวลาตอบสนองหรือสถิติสำหรับธุรกรรมเหล่านี้คืออะไร? สถานะของทรัพยากรที่ระบบใช้ในกรณีนี้คืออะไร? ตัวบ่งชี้ทางธุรกิจที่คาดว่าจะบรรลุควรมาจากสถิติของสภาพแวดล้อมการผลิต ตัวอย่างเช่น แอปพลิเคชันการผลิต cosmos-hub ของ cosmos-sdk เวลาในการสร้างบล็อกปัจจุบันคือประมาณ 6 วินาที และจำนวนธุรกรรมในแต่ละบล็อก ส่วนใหญ่น้อยกว่า 10 การตั้งค่าดัชนีธุรกิจที่คาดหวังเป็น TPS เป็น 100 นั้นสมเหตุสมผลกว่า (TPS ที่ต่ำเช่นนี้จริง ๆ แล้วเกี่ยวข้องกับเป้าหมายของ cosmos-hub เนื่องจากจุดสนใจหลักอยู่ที่ความสามารถในการทำงานร่วมกันของห่วงโซ่)
2. โมเดลทดสอบ: เป็นนามธรรมของฉากจริง โดยอธิบายว่าโมเดลธุรกิจมีลักษณะอย่างไร ยกตัวอย่าง cosmos-hub โหนด blockchain ที่กระจายไปทั่วโลกจะประมวลผลธุรกรรมเมื่อมีโหนดตัวตรวจสอบความถูกต้องประมาณ 500 ตัวและโหนดตัวตรวจสอบความถูกต้องที่ใช้งานอยู่ประมาณ 200 ตัว สถานการณ์จริงสามารถสรุปเป็นมาตราส่วนได้เมื่อทำการทดสอบ
3. แผนการทดสอบ: รวมถึงสภาพแวดล้อมการทดสอบ ข้อมูลการทดสอบ แบบจำลองการทดสอบ ตัวบ่งชี้ประสิทธิภาพ ฯลฯ การทดสอบเปรียบเทียบระบบ blockchain คือการกำหนดโครงสร้างการทดสอบและเตรียมเนื้อหา เช่น ผู้ใช้ 1,000 คน และยอดคงเหลือ 1,000 สเตคของผู้ใช้แต่ละคน
4. จำเป็นต้องมีการมอนิเตอร์: อ็อบเจ็กต์มอนิเตอร์ประกอบด้วยการกด โหนดบล็อกเชน และอื่นๆ เช่น เซิร์ฟเวอร์โหลดบาลานซ์ การตรวจสอบในยุคคลาวด์เนทีฟโดยทั่วไปคือ Kubernetes+Prometheus+Grafana
5. เงื่อนไขการทดสอบที่จำเป็น: สภาพแวดล้อมของฮาร์ดแวร์ กลยุทธ์การดำเนินการทดสอบ ฯลฯ ตัวอย่างเช่น: 4 C 8 G สำหรับ 60 วินาทีแรก ให้เพิ่ม 10 เธรดต่อวินาที
7. มีรายงานผล: เนื้อหาของรายงานเป็นข้อมูลบ่งชี้จริง
ชื่อเรื่องรอง
การจำแนกสถานการณ์ประสิทธิภาพ
1. สถานการณ์ประสิทธิภาพพื้นฐาน: ทำธุรกรรมเดียว/ความจุ (ปริมาณการรับส่งข้อมูล) ของอินเทอร์เฟซ และเตรียมพร้อมสำหรับความจุแบบผสม
2. (ผสม) สถานการณ์ประสิทธิภาพความจุ: การทดสอบความจุแบบผสมเป็นเพราะฉากออนไลน์จริงประกอบด้วยบริการที่แตกต่างกัน ดังนั้นการทดสอบแรงกดไล่ระดับสีที่เริ่มต้นโดยบริการเหล่านี้ตามอัตราส่วนการทำงานพร้อมกันที่แตกต่างกันจึงเป็นสถานการณ์ทดสอบความจุแบบผสม
4. สถานการณ์ประสิทธิภาพที่ผิดปกติ: ภายใต้ความกดดันสูง ให้จำลองความผิดปกติ
ชื่อเรื่องรอง
ตัวบ่งชี้ประสิทธิภาพที่สำคัญ
1. RT, Response Time
2. HPS, Hits Per Second
3. TPS, Transactions Per Second,มีตัวบ่งชี้มากมายสำหรับการทดสอบประสิทธิภาพ เช่น:
4. QPS, Queries Per Second
5. PV, Page View
6. Throughput
7. IOPS, Input/Output Operations Per Second
ธุรกรรมที่นี่โดยทั่วไปเรียกว่า "ธุรกรรม" ในแอปพลิเคชันดั้งเดิม และ "ธุรกรรม" ในฟิลด์บล็อกเชน
ตัวบ่งชี้ที่สำคัญกว่าคือการใช้ทรัพยากร ปริมาณงาน และเวลาตอบสนอง ผู้ให้บริการ ให้ความสำคัญกับสองสิ่งแรกมากกว่า และผู้ใช้ อัปเดตสิ่งหลัง สถานการณ์ทั่วไปของตัวบ่งชี้เหล่านี้แสดงโดยอ้างอิงจากไดอะแกรมแบบคลาสสิกใน Performance Testing Methodology (http://hosteddocs.ittoolbox.com/questnolg 22106 java.pdf) และสถานการณ์จริงอาจแตกต่างออกไป ในรูปมีการกำหนดเส้น 3 เส้น 3 พื้นที่ และ 3 สถานะ ตัวเลขนี้ควรค่าแก่การดูมากขึ้นและคุณสามารถเข้าใจความสัมพันธ์ระหว่างตัวบ่งชี้ได้คร่าวๆ
1. 3 สาย: การใช้งาน, ปริมาณงาน, เวลาตอบสนอง
ชื่อเรื่องรอง
อื่น
อื่น
1. โดยทั่วไป การทดสอบประสิทธิภาพจำเป็นต้องทำเมื่อใด
ก. ก่อนที่โครงการจะออนไลน์ ให้ประเมินความสามารถในการรองรับของระบบ
ข. หลังจากปรับโครงสร้างโครงการแล้ว ให้ประเมินผล
2. ยุติโครงการหากได้รับรายงานประสิทธิภาพ ดังนั้นจึงเป็นเพียงการตรวจสอบประสิทธิภาพเท่านั้น การทดสอบประสิทธิภาพที่ครอบคลุมและการปรับแต่งระบบให้อยู่ในสถานะที่เหมาะสมที่สุดในเวลาเดียวกันถือเป็นโครงการประสิทธิภาพที่สมบูรณ์ การปรับแต่งประสิทธิภาพใช้เวลานานและอาจต้องมีส่วนร่วมกับการพัฒนาซึ่งมีค่าใช้จ่ายสูง
การทดสอบประสิทธิภาพของบล็อกเชนWhy blockchain performance is hard to measureชื่อเรื่องรอง
ล่าช้า
ล่าช้า
จุดเริ่มต้นและจุดสิ้นสุดของช่วงเวลาที่ล่าช้านี้กำหนดไว้อย่างไร?
1. จุดเริ่มต้นคือผู้ใช้คลิกส่งหรือธุรกรรมมาถึง mempool หรือไม่
2. จุดสิ้นสุดคือการทำธุรกรรมได้รับการยืนยันโดยบล็อคแรก? หรือได้รับการยืนยันโดยบล็อกที่ 6 (บล็อกเชน POW คิดอย่างนั้น)? หรือเมื่อผู้ใช้ได้รับการตอบสนองจากอินเทอร์เฟซ?
3. ระบบบล็อกเชนบางระบบรอให้เกิดความล่าช้าและธุรกรรมจำนวนหนึ่งก่อนที่จะเริ่มดำเนินการ ด้วยวิธีนี้ ธุรกรรมที่โชคดีที่สุดจะเข้าร่วมเป็นคนสุดท้าย และความล่าช้าในการดำเนินการจะสั้นที่สุด
5. การประมวลผลธุรกรรมของระบบ blockchain บางระบบมีความสำคัญ ธุรกรรมที่มีค่าธรรมเนียมสูงจะได้รับการยืนยันอย่างรวดเร็ว ในขณะที่ธุรกรรมที่มีค่าธรรมเนียมต่ำจะค่อนข้างช้า ความแตกต่างของค่าธรรมเนียมมีผลกระทบต่อความล่าช้าในการทำธุรกรรมและสถิติ TPS
ชื่อเรื่องรอง
ปริมาณงาน
ปัญหาในทางปฏิบัติอีกประการหนึ่งคือผู้ใช้ไม่สนใจ TPS ของ blockchain จริงๆ ผู้ใช้สนใจแต่วิธีการใช้ค่าธรรมเนียมน้อยลงและทำธุรกรรมให้เสร็จสิ้นโดยเร็วที่สุด จากมุมมองนี้ TPS มีความหมายต่อผู้ให้บริการระบบเท่านั้น
เครื่องมือพื้นฐาน
ชื่อเรื่องรอง
เครื่องมือแรงดันJmeterเครื่องมือแรงดันสำหรับการใช้งานทั่วไป
4. …
หรือเครื่องมือทดสอบเฉพาะการใช้งานเฉพาะดังนี้
การใช้ Jmeter ควรใกล้เคียงกับสถานการณ์การใช้งานและทั่วๆ ไป โดยทั่วไปมีวิธีการโต้ตอบกับโหนด blockchain (การโต้ตอบบรรทัดคำสั่งทั่วไปคือการเรียกหนึ่งในอินเทอร์เฟซต่อไปนี้)
1. โปรโตคอล gRPC
แซมเพลอร์ที่สนับสนุนโดย Jmeter รองรับ HTTP และการรองรับโปรโตคอล gRPC ต้องการความช่วยเหลือจากปลั๊กอินjmeter-grpc-request
ชื่อเรื่องรอง
เครื่องมือตรวจสอบPrometheusเครื่องมือตรวจสอบทั่วไปhttps://prometheus.io/assets/architecture.pngเครื่องมือนี้สามารถตรวจสอบเนื้อหาจำนวนมาก และระบบนิเวศของมันจะแสดงในรูป (
). ในทางปฏิบัติของการทดสอบแอปพลิเคชัน blockchain โดยทั่วไปจะใช้ docker-compose เพื่อปรับใช้โหนด blockchain หลายโหนดเพื่อจำลองสภาพแวดล้อมการทดสอบอย่างเป็นทางการ เนื่องจากสภาพแวดล้อมการทดสอบอย่างเป็นทางการโดยทั่วไปมีการกำหนดค่าฮาร์ดแวร์สูง ถ้าไม่ใช่ห้องคอมพิวเตอร์ที่สร้างขึ้นเอง ให้ใช้ คลาวด์ เครื่องจักรของผู้ผลิตบริการมีราคาแพง และสิ่งนี้สามารถประหยัดค่าใช้จ่ายได้cadvisor。
ใน docker-compose คุณสามารถจำกัดทรัพยากรที่ใช้โดยคอนเทนเนอร์ เช่น หน่วยความจำและพลังการประมวลผลของ CPU และแม้แต่ผูกแกน CPU การตรวจสอบทรัพยากรเหล่านี้สามารถใช้ได้stress-ngรูปภาพ
ชื่อระดับแรก
การปรับแต่งประสิทธิภาพ
โดยทั่วไปแล้ว สาเหตุเมตาทั่วไปของปัญหาคอขวดด้านประสิทธิภาพ (ฉันเรียกสาเหตุเหล่านี้ว่าสาเหตุเบื้องหลัง มักจะอยู่ที่ระดับฮาร์ดแวร์) ได้แก่ เครือข่าย, CPU และดิสก์ IO การดำเนินการที่ทำให้เกิดคอขวดของดิสก์ IO ได้แก่ การเขียนบันทึกบ่อยครั้ง การพิมพ์บันทึกโดยไม่จำเป็น และการเข้าถึงดิสก์ผ่านเครือข่าย ทรัพยากรเหล่านี้จะเสร็จสมบูรณ์ผ่านการเรียกระบบ ในการติดตามการเรียกระบบ คุณสามารถใช้ strace เพื่อดูว่าการเรียกระบบใดที่ดำเนินการและเวลาที่ใช้ในการโทรเหล่านี้
อีกปัญหาหนึ่งที่อาจพบคือความไม่เสถียรของระบบ ซึ่งอาจแสดงออกมาว่าเป็นการใช้งาน CPU/ความไม่เสถียรของ TPS
หากการใช้งาน CPU ไม่เสถียร (แนวโน้มคงที่ แต่ผันผวนอย่างมาก) จากมุมมองของการดำเนินการตามคำสั่ง CPU หมายความว่า CPU อยู่ในสถานะไม่ได้ใช้งานเป็นระยะเวลาต่างๆ กัน เหตุผลในกรณีนี้ไม่ใช่ว่ามี CPU ที่ไม่ได้ใช้งาน แต่มีช่วงเวลาที่ไม่ได้ใช้งานนั้นยาวหรือสั้น คุณต้องใช้เครื่องมือระบบ Linux และเครื่องมือสร้างโปรไฟล์ที่เกี่ยวข้องกับโปรแกรมเพื่อสังเกตและค้นหาสาเหตุ
ชื่อเรื่องรอง
เครื่องมือวิเคราะห์https://www.brendangregg.com/Perf/linux_perf_tools_full.pngรูปภาพ
ชื่อเรื่องรอง
โดยทั่วไปแล้ว Disk IO จะนำไปสู่ปัญหาคอขวดของระบบ และสแต็ค IO ของดิสก์นั้นค่อนข้างยาว ทำให้ยากต่อการวิเคราะห์ ความคุ้นเคยกับ IO stack จะช่วยให้เราค้นหาปัญหา (https://www.thomas-krenn.com/en/wikiEN/images/c/c 2/Linux-storage-stack-diagram_v 6.2.pdf)
รูปภาพ
หลังจากค้นหาสาเหตุแล้ว จะเร็วขึ้นในการเพิ่มประสิทธิภาพโดยการปรับพารามิเตอร์ระบบปฏิบัติการหรือพารามิเตอร์ระบบแอปพลิเคชัน หากคุณต้องการแก้ไขโค้ด จะเกี่ยวข้องกับการปรับสถาปัตยกรรมระบบให้เหมาะสม เกี่ยวข้องกับและเข้ารหัสงาน และรอบการปรับแต่งจะยาวมาก .


