หนึ่งในปัญหาที่ผู้จำหน่ายซอฟต์แวร์หลายผลิตภัณฑ์มักเผชิญคือการซ้ำซ้อนของความสามารถของวิศวกร - นักพัฒนา ผู้ทดสอบ และผู้ดูแลระบบโครงสร้างพื้นฐาน - ในเกือบทุกทีม นอกจากนี้ยังใช้กับวิศวกรที่มีราคาแพง - ผู้เชี่ยวชาญในด้านการทดสอบโหลด
แทนที่จะทำหน้าที่โดยตรงและใช้ประสบการณ์เฉพาะในการสร้างกระบวนการทดสอบโหลด เลือกวิธีการ เมตริกที่เหมาะสมที่สุด และเขียนการทดสอบอัตโนมัติตามโปรไฟล์โหลด วิศวกรมักต้องปรับใช้โครงสร้างพื้นฐานการทดสอบตั้งแต่เริ่มต้น กำหนดค่าเครื่องมือโหลด และฝัง ตนเองในระบบ CI ตั้งค่าการตรวจสอบและเผยแพร่รายงาน
คุณสามารถค้นหาวิธีแก้ไขปัญหาขององค์กรได้ในการทดสอบที่เราใช้ที่ Positive Technologies ใน . และในบทความนี้ ฉันจะพูดถึงความเป็นไปได้ในการรวมการทดสอบโหลดเข้ากับไปป์ไลน์ CI ทั่วไปโดยใช้แนวคิดของ "การทดสอบโหลดในฐานะบริการ" (การทดสอบโหลดในฐานะบริการ) คุณจะได้เรียนรู้วิธีการและอิมเมจนักเทียบท่าของโหลดซอร์สที่สามารถใช้ในไปป์ไลน์ CI วิธีเชื่อมต่อโหลดซอร์สกับโปรเจ็กต์ CI ของคุณโดยใช้เทมเพลตบิลด์ ไปป์ไลน์สาธิตมีลักษณะอย่างไรสำหรับการเรียกใช้การทดสอบโหลดและการเผยแพร่ผลลัพธ์ บทความนี้อาจเป็นประโยชน์สำหรับวิศวกรทดสอบซอฟต์แวร์และวิศวกรระบบอัตโนมัติใน CI ที่กำลังคิดเกี่ยวกับสถาปัตยกรรมของระบบโหลดของตน
สาระสำคัญของแนวคิด
แนวคิดของการทดสอบโหลดเป็นบริการแสดงถึงความสามารถในการรวมเครื่องมือโหลด Apache JMeter, Yandex.Tank และเฟรมเวิร์กของคุณเองเข้ากับระบบการรวมอย่างต่อเนื่องตามอำเภอใจ การสาธิตจะใช้สำหรับ GitLab CI แต่หลักการนั้นเหมือนกันกับระบบ CI ทั้งหมด
Load Testing as a Service เป็นบริการแบบรวมศูนย์สำหรับการทดสอบโหลด การทดสอบการโหลดจะดำเนินการในกลุ่มตัวแทนเฉพาะ ผลลัพธ์จะถูกเผยแพร่โดยอัตโนมัติใน GitLab Pages, Influx DB และ Grafana หรือในระบบรายงานการทดสอบ (TestRail, ReportPortal เป็นต้น) การทำงานอัตโนมัติและการปรับขนาดนั้นถูกนำมาใช้อย่างง่ายที่สุดเท่าที่จะเป็นไปได้ - ผ่านการเพิ่มและการกำหนดพารามิเตอร์ในโครงการ GitLab CI ของเทมเพลต gitlab-ci.yml ปกติ
ข้อดีของแนวทางนี้คือโครงสร้างพื้นฐาน CI ทั้งหมด ตัวแทนโหลด รูปภาพนักเทียบท่าของแหล่งโหลด ท่อทดสอบ และรายงานการเผยแพร่จะได้รับการดูแลโดยแผนกอัตโนมัติส่วนกลาง (วิศวกร DevOps) ในขณะที่วิศวกรทดสอบโหลดสามารถมุ่งเน้นไปที่การพัฒนาการทดสอบ และการวิเคราะห์ผลลัพธ์โดยไม่เกี่ยวข้องกับปัญหาด้านโครงสร้างพื้นฐาน
เพื่อความเรียบง่ายของคำอธิบาย เราจะถือว่าแอปพลิเคชันเป้าหมายหรือเซิร์ฟเวอร์ภายใต้การทดสอบได้รับการปรับใช้และกำหนดค่าล่วงหน้าแล้ว (สามารถใช้สคริปต์อัตโนมัติใน Python, SaltStack, Ansible และอื่นๆ สำหรับสิ่งนี้) จากนั้นแนวคิดทั้งหมดของการทดสอบโหลดในฐานะบริการจะแบ่งออกเป็นสามขั้นตอน: การจัดทำ การทดสอบ การตีพิมพ์รายงาน. รายละเอียดเพิ่มเติมเกี่ยวกับไดอะแกรม (รูปภาพทั้งหมดสามารถคลิกได้):
แนวคิดและคำจำกัดความพื้นฐานในการทดสอบโหลด
เมื่อทำการทดสอบโหลด เราพยายามปฏิบัติตาม ใช้คำศัพท์ที่เหมาะสมและเมตริกที่แนะนำ ฉันจะให้รายการสั้น ๆ ของแนวคิดหลักและคำจำกัดความในการทดสอบโหลด
ตัวแทนโหลด - เครื่องเสมือนที่จะเปิดตัวแอปพลิเคชัน - แหล่งโหลด (Apache JMeter, Yandex.Tank หรือโมดูลโหลดที่เขียนเอง)
เป้าหมายการทดสอบ (เป้าหมาย) - เซิร์ฟเวอร์หรือแอปพลิเคชันที่ติดตั้งบนเซิร์ฟเวอร์ที่จะถูกโหลด
สถานการณ์ทดสอบ (กรณีทดสอบ) - ชุดของขั้นตอนที่กำหนดพารามิเตอร์: การกระทำของผู้ใช้และปฏิกิริยาที่คาดหวังต่อการกระทำเหล่านี้ พร้อมคำขอและการตอบสนองของเครือข่ายคงที่ ขึ้นอยู่กับพารามิเตอร์ที่ระบุ
โปรไฟล์หรือแผนการโหลด (โปรไฟล์) - ใน (ส่วน 4.2.4 หน้า 43) โหลดโปรไฟล์กำหนดเมตริกที่สำคัญสำหรับการทดสอบเฉพาะและตัวเลือกสำหรับการเปลี่ยนพารามิเตอร์โหลดระหว่างการทดสอบ คุณสามารถดูตัวอย่างโปรไฟล์ได้ในรูป
ทดสอบ — สคริปต์ที่มีชุดพารามิเตอร์ที่กำหนดไว้ล่วงหน้า
แผนการทดสอบ (แผนการทดสอบ) - ชุดทดสอบและโหลดโปรไฟล์
Testran (เทสรัน) - การวนซ้ำหนึ่งรอบของการเรียกใช้การทดสอบหนึ่งครั้งด้วยสถานการณ์การโหลดที่ดำเนินการอย่างสมบูรณ์และรายงานที่ได้รับ
คำขอเครือข่าย (คำขอ) — คำขอ HTTP ที่ส่งจากตัวแทนไปยังเป้าหมาย
การตอบสนองของเครือข่าย (การตอบสนอง) — การตอบสนอง HTTP ที่ส่งจากเป้าหมายไปยังตัวแทน
รหัสตอบกลับ HTTP (สถานะการตอบกลับ HTTP) - รหัสตอบกลับมาตรฐานจากแอปพลิเคชันเซิร์ฟเวอร์
การทำธุรกรรมเป็นวงจรการตอบสนองคำขอที่สมบูรณ์ การทำธุรกรรมจะนับจากจุดเริ่มต้นของการส่งคำขอ (คำขอ) ไปจนถึงการได้รับการตอบสนอง (การตอบสนอง)
สถานะการทำธุรกรรม - เป็นไปได้ไหมที่จะเสร็จสิ้นรอบการตอบกลับคำขอ หากมีข้อผิดพลาดใดๆ ในรอบนี้ ธุรกรรมทั้งหมดจะถือว่าไม่สำเร็จ
เวลาตอบสนอง (เวลาแฝง) - เวลาตั้งแต่สิ้นสุดการส่งคำขอ (คำขอ) จนถึงจุดเริ่มต้นของการตอบกลับ (ตอบกลับ)
โหลดเมตริก — ลักษณะของบริการที่โหลดและตัวแทนโหลดที่กำหนดในกระบวนการทดสอบโหลด
เมตริกพื้นฐานสำหรับการวัดพารามิเตอร์โหลด
บางส่วนที่ใช้บ่อยที่สุดและแนะนำในวิธีการ (น. 36, 52) เมตริกแสดงในตารางด้านล่าง เมตริกที่คล้ายกันสำหรับตัวแทนและเป้าหมายแสดงอยู่ในบรรทัดเดียวกัน
เมตริกสำหรับตัวแทนการโหลด
เมตริกของระบบเป้าหมายหรือแอปพลิเคชันที่กำลังทดสอบภายใต้โหลด
จำนวน ซีพียู และหน่วยความจำ แรม,
ดิสก์ - ลักษณะ "เหล็ก" ของตัวแทนโหลด
ซีพียู, หน่วยความจำ การใช้งานดิสก์ - พลวัตของ CPU, หน่วยความจำและการโหลดดิสก์
อยู่ในขั้นตอนการทดสอบ โดยปกติจะวัดเป็นเปอร์เซ็นต์ของ
ค่าสูงสุดที่มีอยู่
ปริมาณงานเครือข่าย (ตัวแทนโหลด) - ปริมาณงาน
อินเทอร์เฟซเครือข่ายบนเซิร์ฟเวอร์
ตำแหน่งโหลดเอเจนต์ถูกติดตั้ง
โดยปกติจะวัดเป็นไบต์ต่อวินาที (bps)
ปริมาณงานเครือข่าย(ตามเป้าหมาย) - แบนด์วิดท์อินเทอร์เฟซเครือข่าย
บนเซิร์ฟเวอร์เป้าหมาย โดยปกติจะวัดเป็นไบต์ต่อวินาที (bps)
ผู้ใช้เสมือนจริง- จำนวนผู้ใช้เสมือน
การใช้สถานการณ์การโหลดและ
เลียนแบบการกระทำของผู้ใช้จริง
สถานะผู้ใช้เสมือน, ผ่าน/ไม่ผ่าน/รวม — จำนวนครั้งที่สำเร็จ และ
สถานะที่ไม่สำเร็จของผู้ใช้เสมือน
สำหรับสถานการณ์การโหลด ตลอดจนจำนวนทั้งหมด
โดยทั่วไปคาดว่าผู้ใช้ทั้งหมดจะสามารถดำเนินการให้เสร็จสิ้นได้
งานทั้งหมดของคุณที่ระบุในโหลดโปรไฟล์
ข้อผิดพลาดใด ๆ จะหมายความว่าผู้ใช้จริงจะไม่สามารถ
แก้ปัญหาของคุณเมื่อทำงานกับระบบ
คำขอต่อวินาที (นาที)- จำนวนคำขอเครือข่ายต่อวินาที (หรือนาที)
คุณลักษณะที่สำคัญของเอเจนต์การโหลดคือจำนวนคำขอที่สามารถสร้างได้
อันที่จริงแล้ว นี่เป็นการเลียนแบบการเข้าถึงแอปพลิเคชันโดยผู้ใช้เสมือน
การตอบสนองต่อวินาที (นาที)
- จำนวนการตอบสนองของเครือข่ายต่อวินาที (หรือนาที)
ลักษณะสำคัญของบริการเป้าหมาย: เท่าไหร่
สร้างและส่งการตอบคำถามด้วย
ตัวแทนโหลด
สถานะการตอบสนอง HTTP— จำนวนรหัสตอบกลับที่แตกต่างกัน
จากแอ็พพลิเคชันเซิร์ฟเวอร์ที่ได้รับจากเอเจนต์การโหลด
ตัวอย่างเช่น 200 OK หมายถึงการโทรสำเร็จ
และ 404 - ไม่พบทรัพยากร
ความแอบแฝง (เวลาตอบสนอง) - เวลาจากจุดสิ้นสุด
ส่งคำขอ (คำขอ) ก่อนเริ่มรับการตอบกลับ (ตอบกลับ)
โดยปกติจะวัดเป็นมิลลิวินาที (ms)
เวลาตอบสนองการทำธุรกรรม— เวลาของการทำธุรกรรมเต็มรูปแบบหนึ่งครั้ง
เสร็จสิ้นรอบการตอบกลับคำขอ
นี่คือเวลาตั้งแต่เริ่มส่งคำขอ (คำขอ)
จนกว่าจะได้รับการตอบสนอง (response) เสร็จสิ้น
เวลาในการทำธุรกรรมสามารถวัดเป็นวินาที (หรือนาที)
ในหลายวิธี: พิจารณาขั้นต่ำ
สูงสุด ค่าเฉลี่ย และตัวอย่างเช่น เปอร์เซ็นไทล์ที่ 90
การอ่านค่าต่ำสุดและสูงสุดนั้นรุนแรงมาก
สถานะประสิทธิภาพของระบบ
เปอร์เซ็นไทล์ที่ XNUMX เป็นค่าที่ใช้บ่อยที่สุด
ดังที่แสดงให้ผู้ใช้ส่วนใหญ่เห็นว่า
ทำงานอย่างสะดวกสบายที่เกณฑ์ประสิทธิภาพของระบบ
การทำธุรกรรมต่อวินาที (นาที) - จำนวนที่สมบูรณ์
ธุรกรรมต่อวินาที (นาที)
นั่นคือแอปพลิเคชันสามารถยอมรับได้มากน้อยเพียงใด และ
ดำเนินการตามคำขอและการตอบสนองปัญหา
ในความเป็นจริงนี่คือปริมาณงานของระบบ
สถานะการทำธุรกรรม , ผ่าน / ไม่ผ่าน / รวม - จำนวน
สำเร็จ ไม่สำเร็จ และจำนวนธุรกรรมทั้งหมด
สำหรับผู้ใช้จริงไม่สำเร็จ
การทำธุรกรรมจะหมายถึง
ไม่สามารถทำงานกับระบบภายใต้โหลด
โหลดไดอะแกรมแผนผังการทดสอบ
แนวคิดของการทดสอบโหลดนั้นง่ายมาก และประกอบด้วยสามขั้นตอนหลัก ซึ่งฉันได้กล่าวถึงแล้ว: เตรียม-ทดสอบ-รายงานนั่นคือ การเตรียมเป้าหมายการทดสอบและการตั้งค่าพารามิเตอร์สำหรับแหล่งโหลด จากนั้นดำเนินการทดสอบโหลด และในตอนท้าย สร้างและเผยแพร่รายงานการทดสอบ
หมายเหตุแผนผัง:
- QA.Tester เป็นผู้เชี่ยวชาญในการทดสอบโหลด
- Target คือแอ็พพลิเคชันเป้าหมายที่คุณต้องการทราบพฤติกรรมภายใต้การโหลด
ลักษณนามของเอนทิตี ขั้นตอน และขั้นตอนในแผนภาพ
ขั้นตอนและขั้นตอน
เกิดอะไรขึ้น
อะไรอยู่ที่ทางเข้า
ผลลัพธ์คืออะไร
เตรียม: ขั้นตอนการเตรียมการสำหรับการทดสอบ
โหลดพารามิเตอร์
การตั้งค่าและการเริ่มต้น
ผู้ใช้
โหลดพารามิเตอร์
ทางเลือกของเมตริกและ
การเตรียมแผนการทดสอบ
(โหลดโปรไฟล์)
ตัวเลือกที่กำหนดเองสำหรับ
การเริ่มต้นตัวแทนการโหลด
แผนการทดสอบ
วัตถุประสงค์ของการทดสอบ
VM
การปรับใช้คลาวด์
เครื่องเสมือนด้วย
ลักษณะที่จำเป็น
การตั้งค่า VM สำหรับเอเจนต์การโหลด
สคริปต์การทำงานอัตโนมัติสำหรับ
การสร้าง VM
VM กำหนดค่าใน
คลาวด์
env
การตั้งค่าและการเตรียม OS
สภาพแวดล้อมสำหรับ
งานตัวแทนโหลด
การตั้งค่าสภาพแวดล้อมสำหรับ
ตัวแทนโหลด
สคริปต์การทำงานอัตโนมัติสำหรับ
การตั้งค่าสภาพแวดล้อม
สภาพแวดล้อมที่เตรียมไว้:
ระบบปฏิบัติการ บริการ และแอปพลิเคชัน
จำเป็นสำหรับการทำงาน
ตัวแทนโหลด
โหลดเอเจนต์
การติดตั้ง การกำหนดค่า และการกำหนดพารามิเตอร์
ตัวแทนโหลด
หรือดาวน์โหลดอิมเมจนักเทียบท่าจาก
โหลดซอร์สที่กำหนดค่าไว้ล่วงหน้า
โหลดอิมเมจนักเทียบท่าต้นทาง
(YAT, JM หรือเฟรมเวิร์กที่เขียนขึ้นเอง)
การตั้งค่า
ตัวแทนโหลด
ตั้งค่าและพร้อม
ตัวแทนภาระงาน
การทดสอบ: ขั้นตอนของการดำเนินการทดสอบโหลด แหล่งที่มาคือตัวแทนโหลดที่ปรับใช้ในกลุ่มตัวแทนเฉพาะสำหรับ GitLab CI
โหลด
การเริ่มต้น Load Agent
ด้วยแผนการทดสอบที่เลือก
และโหลดพารามิเตอร์
ตัวเลือกผู้ใช้
สำหรับการเริ่มต้น
ตัวแทนโหลด
แผนการทดสอบ
วัตถุประสงค์ของการทดสอบ
บันทึกการดำเนินการ
โหลดการทดสอบ
บันทึกของระบบ
ไดนามิกของการเปลี่ยนแปลงในเมตริกเป้าหมายและเอเจนต์การบรรทุก
เรียกใช้ตัวแทน
การดำเนินการของตัวแทน
โหลดสคริปต์ทดสอบ
ตามด้วย
โหลดโปรไฟล์
โหลดการโต้ตอบตัวแทน
เพื่อจุดประสงค์ในการทดสอบ
แผนการทดสอบ
วัตถุประสงค์ของการทดสอบ
ท่อน
การรวบรวมบันทึก "ดิบ"
ระหว่างการทดสอบโหลด:
โหลดบันทึกกิจกรรมตัวแทน
สถานะของเป้าหมายการทดสอบ
และ VM ที่รันเอเจนต์
บันทึกการดำเนินการ
โหลดการทดสอบ
บันทึกของระบบ
ตัวชี้วัด
รวบรวมเมตริก "ดิบ" ระหว่างการทดสอบ
ไดนามิกของการเปลี่ยนแปลงในเมตริกเป้าหมาย
และตัวแทนโหลด
รายงาน: ขั้นตอนการเตรียมรายงานการทดสอบ
เครื่องกำเนิดไฟฟ้า
รวบรวมการประมวลผล
ระบบโหลดและ
ระบบตรวจสอบ "ดิบ"
เมตริกและบันทึก
การจัดทำรายงานใน
รูปแบบที่มนุษย์อ่านได้
เป็นไปได้ด้วยองค์ประกอบ
นักวิเคราะห์
บันทึกการดำเนินการ
โหลดการทดสอบ
บันทึกของระบบ
พลวัตของการเปลี่ยนแปลงในเมตริก
เป้าหมายและตัวแทนโหลด
ประมวลผลบันทึก "ดิบ"
ในรูปแบบที่เหมาะกับ
อัปโหลดไปยังที่จัดเก็บข้อมูลภายนอก
รายงานโหลดคงที่
มนุษย์อ่านได้
สาธารณะ
การเผยแพร่รายงาน
เกี่ยวกับโหลด
การทดสอบภายนอก
บริการ
แปรรูป "ดิบ"
บันทึกในรูปแบบที่เหมาะสม
สำหรับการขนถ่ายไปยังภายนอก
คลังเก็บ
บันทึกไว้ในภายนอก
เปิดรายงานการจัดเก็บ
โหลดเหมาะ
สำหรับการวิเคราะห์ของมนุษย์
กำลังเชื่อมต่อโหลดซอร์สในเทมเพลต CI
ไปที่ส่วนปฏิบัติกันเถอะ ฉันต้องการแสดงวิธีการในโครงการบางโครงการในบริษัท เราได้ใช้แนวคิดของการทดสอบโหลดเป็นบริการ
อันดับแรก ด้วยความช่วยเหลือจากวิศวกร DevOps เราสร้างกลุ่มตัวแทนเฉพาะใน GitLab CI เพื่อเรียกใช้การทดสอบโหลด เพื่อไม่ให้สับสนในเทมเพลตกับผู้อื่น เช่น พูลแอสเซมบลี เราได้เพิ่มแท็กให้กับเอเจนต์เหล่านี้ : โหลด. คุณสามารถใช้แท็กอื่นๆ ที่เข้าใจได้ พวกเขาถาม นักวิ่ง GitLab CI
จะหาพลังงานที่ต้องการโดยฮาร์ดแวร์ได้อย่างไร? คุณลักษณะของเอเจนต์โหลด - จำนวน vCPU, RAM และดิสก์ที่เพียงพอ - สามารถคำนวณได้จากความจริงที่ว่า Docker, Python (สำหรับ Yandex.Tank), ตัวแทน GitLab CI, Java (สำหรับ Apache JMeter) ควรทำงานบนเอเจนต์ . สำหรับ Java ภายใต้ JMeter ขอแนะนำให้ใช้ RAM อย่างน้อย 512 MB และเป็นขีดจำกัดสูงสุด .
ดังนั้น จากประสบการณ์ของเรา เราแนะนำให้ใช้ vCPU อย่างน้อย 4 ตัว, RAM 4 GB, SSD 60 GB สำหรับเอเจนต์โหลด ทรูพุตของการ์ดเครือข่ายจะพิจารณาจากข้อกำหนดของโหลดโปรไฟล์
เราใช้แหล่งโหลดสองแหล่งเป็นหลัก - อิมเมจ Apache JMeter และ Yandex.Tank
เป็นเครื่องมือโอเพ่นซอร์สจาก Yandex สำหรับการทดสอบโหลด สถาปัตยกรรมโมดูลาร์อิงตามตัวสร้างคำขอ HTTP แบบอะซิงโครนัสแบบอะซิงโครนัสที่มีประสิทธิภาพสูงของ Phantom รถถังมีการตรวจสอบทรัพยากรของเซิร์ฟเวอร์ภายใต้การทดสอบผ่านโปรโตคอล SSH ในตัว สามารถหยุดการทดสอบโดยอัตโนมัติภายใต้เงื่อนไขที่กำหนด สามารถแสดงผลได้ทั้งในคอนโซลและในรูปแบบของกราฟ คุณสามารถเชื่อมต่อโมดูลของคุณกับ เพื่อขยายการทำงาน ยังไงก็ตาม เราใช้รถถังตอนที่ยังไม่เป็นกระแสหลัก ในบทความ "» คุณสามารถอ่านเรื่องราวของวิธีที่เราทำการทดสอบโหลดกับมันในปี 2013 เป็นหนึ่งในผลิตภัณฑ์ของบริษัทเรา
JMeter เป็นเครื่องมือทดสอบโหลดแบบโอเพนซอร์สจาก Apache สามารถใช้ทดสอบเว็บแอปพลิเคชันทั้งแบบคงที่และแบบไดนามิกได้อย่างมีประสิทธิภาพ JMeter รองรับโปรโตคอลและวิธีการโต้ตอบกับแอปพลิเคชันจำนวนมาก เช่น HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET ฯลฯ), SOAP / REST Webservices, FTP, TCP, LDAP, SMTP(S), POP3(S) และ IMAP(S), ฐานข้อมูลผ่าน JDBC, สามารถเรียกใช้คำสั่ง shell และทำงานกับอ็อบเจ็กต์ Java ได้ JMeter มี IDE สำหรับสร้าง ดีบัก และเรียกใช้แผนการทดสอบ นอกจากนี้ยังมี CLI สำหรับทำงานจากบรรทัดคำสั่งของระบบปฏิบัติการที่เข้ากันได้กับ Java (Linux, Windows(Mac OS X) เครื่องมือนี้สามารถสร้างรายงานการทดสอบในรูปแบบ HTML ได้แบบไดนามิก
เพื่อความสะดวกในการใช้งานภายในบริษัทของเรา สำหรับความสามารถของผู้ทดสอบเองในการเปลี่ยนแปลงและเพิ่มสภาพแวดล้อม เราได้สร้างอิมเมจนักเทียบท่าของโหลดซอร์สบน GitLab CI พร้อมเผยแพร่ไปยังภายใน . สิ่งนี้ทำให้การเชื่อมต่อในท่อสำหรับการทดสอบโหลดทำได้เร็วและง่ายขึ้น วิธีทำ docker push to Registry ผ่าน GitLab CI - ดู .
เราใช้ไฟล์นักเทียบท่าพื้นฐานนี้สำหรับ Yandex.Tank:
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]และสำหรับ Apache JMeter อันนี้:
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]คุณสามารถอ่านวิธีการทำงานของระบบการผสานรวมอย่างต่อเนื่องของเราได้ในบทความ "'
เทมเพลตและไปป์ไลน์
ตัวอย่างของเทมเพลตสำหรับดำเนินการทดสอบการโหลดมีอยู่ในโครงการ . ใน คุณสามารถอ่านคำแนะนำในการใช้เทมเพลต ในเทมเพลตเอง (ไฟล์ ) มีบันทึกเกี่ยวกับสิ่งที่แต่ละขั้นตอนรับผิดชอบ
เทมเพลตนี้เรียบง่ายมากและแสดงให้เห็นถึงสามขั้นตอนของการทดสอบโหลดที่อธิบายไว้ในไดอะแกรมด้านบน: การเตรียม การทดสอบ และการเผยแพร่รายงาน รับผิดชอบเรื่องนี้ : เตรียม ทดสอบ และรายงาน.
- เวที ควรใช้เพื่อกำหนดค่าเป้าหมายการทดสอบล่วงหน้าหรือตรวจสอบความพร้อมใช้งาน ไม่จำเป็นต้องกำหนดค่าสภาพแวดล้อมสำหรับโหลดซอร์ส โดยสร้างไว้ล่วงหน้าเป็นอิมเมจนักเทียบท่าและโพสต์ในรีจิสทรีนักเทียบท่า: เพียงระบุเวอร์ชันที่ต้องการในขั้นตอนการทดสอบ แต่คุณสามารถสร้างใหม่และสร้างภาพที่แก้ไขของคุณเองได้
- เวที ใช้เพื่อระบุแหล่งโหลด รันการทดสอบ และจัดเก็บวัตถุทดสอบ คุณสามารถเลือกแหล่งโหลดใดก็ได้: Yandex.Tank, Apache JMeter, ของคุณเองหรือทั้งหมดรวมกัน หากต้องการปิดใช้งานแหล่งข้อมูลที่ไม่จำเป็น เพียงแสดงความคิดเห็นหรือลบงาน จุดเริ่มต้นสำหรับโหลดซอร์ส:
- พารามิเตอร์การเปิดตัวสำหรับ Yandex.Tank ระบุไว้ในไฟล์.,
- มีการระบุพารามิเตอร์เริ่มต้น Apache JMeter ในไฟล์ .
หมายเหตุ: เทมเพลตการกำหนดค่าแอสเซมบลีใช้เพื่อตั้งค่าการโต้ตอบกับระบบ CI และไม่ได้หมายความถึงการวางตรรกะการทดสอบในนั้น สำหรับการทดสอบ จะมีการระบุจุดเข้าใช้งานซึ่งเป็นที่ตั้งของสคริปต์ควบคุมการทุบตี วิธีการเรียกใช้การทดสอบ การสร้างรายงาน และสคริปต์การทดสอบจะต้องดำเนินการโดยวิศวกรควบคุมคุณภาพ ในการสาธิต สำหรับแหล่งโหลดทั้งสอง คำขอของหน้าหลักของยานเดกซ์จะถูกใช้เป็นการทดสอบที่ง่ายที่สุด สคริปต์และพารามิเตอร์การทดสอบอยู่ในไดเร็กทอรี .
- ที่เวที คุณต้องอธิบายวิธีเผยแพร่ผลการทดสอบที่ได้รับในขั้นตอนการทดสอบไปยังที่จัดเก็บข้อมูลภายนอก เช่น ไปยัง GitLab Pages หรือระบบรายงานพิเศษ GitLab Pages กำหนดให้ไดเร็กทอรี ./public ต้องไม่ว่างเปล่าและมีไฟล์ index.html เป็นอย่างน้อยหลังจากการทดสอบเสร็จสิ้น คุณสามารถอ่านเกี่ยวกับความแตกต่างของบริการ GitLab Pages .
ตัวอย่างของวิธีการส่งออกข้อมูล:
- จาก JMeter ถึง ,
- จาก Yandex.Tank ถึง .
โพสต์คำแนะนำในการตั้งค่า:
- HTML คงที่ใน ,
- ไปยัง InfluxDB แล้วไปที่ .
ในตัวอย่างการสาธิต ไปป์ไลน์ที่มีการทดสอบโหลดและแหล่งโหลดสองแหล่ง (คุณสามารถปิดใช้งานอันที่ไม่จำเป็นได้) จะมีลักษณะดังนี้:
Apache JMeter สามารถสร้างรายงาน HTML ได้เอง ดังนั้นการบันทึกรายงานใน GitLab Pages โดยใช้เครื่องมือมาตรฐานจึงให้ผลกำไรมากกว่า นี่คือลักษณะของรายงาน Apache JMeter:
ในตัวอย่างการสาธิตสำหรับ Yandex.Tank คุณจะเห็นเท่านั้น ในส่วนของ GitLab Pages ระหว่างการทดสอบ Tank สามารถบันทึกผลลัพธ์ไปยังฐานข้อมูล InfluxDB และจากนั้นสามารถแสดงผลได้ ตัวอย่างเช่น ใน Grafana (การกำหนดค่าเสร็จสิ้นในไฟล์ ). นี่คือลักษณะของรายงานของ Tank ใน Grafana:
สรุป
ในบทความ ฉันได้พูดถึงแนวคิดของ "โหลดการทดสอบเป็นบริการ" (โหลดการทดสอบเป็นบริการ) แนวคิดหลักคือการใช้โครงสร้างพื้นฐานของพูลเอเจนต์โหลดที่กำหนดค่าไว้ล่วงหน้า อิมเมจนักเทียบท่าของโหลดซอร์ส ระบบการรายงาน และไปป์ไลน์ที่รวมไว้ใน GitLab CI ตามเทมเพลต .gitlab-ci.yml แบบง่าย (ตัวอย่าง ). ทั้งหมดนี้ได้รับการสนับสนุนโดยทีมวิศวกรระบบอัตโนมัติกลุ่มเล็กๆ และจำลองตามคำร้องขอของทีมผลิตภัณฑ์ ฉันหวังว่าสิ่งนี้จะช่วยคุณในการเตรียมการและนำแผนการที่คล้ายกันไปใช้ในบริษัทของคุณ ขอบคุณสำหรับความสนใจ!
ป.ล. ฉันอยากจะขอบคุณเพื่อนร่วมงานของฉัน Sergey Kurbanov และ Nikolai Yusev สำหรับความช่วยเหลือด้านเทคนิคเกี่ยวกับการนำแนวคิดการทดสอบโหลดมาใช้ในบริษัทของเรา
ผู้เขียน: - รอง หัวหน้าฝ่ายเทคโนโลยีและกระบวนการพัฒนา (DevOps) ที่ Positive Technologies
ที่มา: will.com
