คุณต้องการทราบว่าจะเกิดอะไรขึ้นกับ API ของคุณเมื่อมีผู้ใช้ 80 คนกดชำระเงินพร้อมกัน ดังนั้นคุณจึงเปิด Locust ขึ้นมา และสิ่งแรกที่มันขอให้คุณทำคือเขียนคลาส Python กำหนด HttpUser ตกแต่งเมธอดด้วย @task สร้างไฟล์ locustfile.py ตั้งค่าสภาพแวดล้อมเสมือน (virtual environment) กำหนด dependencies ไม่กี่ตัว แล้วจึงหาว่าทำไมโทเค็นการรับรองความถูกต้องของคุณถึงไม่ถูกนำกลับมาใช้ใหม่ในการร้องขอต่างๆ ทั้งหมดนี้ไม่ใช่การทดสอบ มันคือค่าใช้จ่ายเบื้องต้นก่อนที่การทดสอบจะเริ่มต้นขึ้น
Locust เป็นเครื่องมือที่ดี และการออกแบบที่เน้นโค้ดเป็นหลักก็คือจุดประสงค์ของมัน แต่ถ้าเป้าหมายของคุณคือคำตอบตรงๆ ว่า "เอนด์พอยต์ล็อกอินของฉันรองรับผู้ใช้พร้อมกัน 100 คนได้หรือไม่" การเขียนและดูแลรักษา Python harness นั้นเป็นงานที่ยุ่งยากเกินไปสำหรับตัวเลขเพียงตัวเดียว มีวิธีที่เร็วกว่าเมื่อคำขอ API ที่คุณต้องการทดสอบนั้นมีอยู่ในไคลเอนต์ API อยู่แล้ว ด้วย Apidog คุณสามารถชี้การทดสอบประสิทธิภาพไปยังสถานการณ์การทดสอบที่มีอยู่แล้ว กำหนดจำนวนผู้ใช้เสมือนและระยะเวลา แล้วอ่านค่าปริมาณงาน (throughput) เวลาตอบสนอง และอัตราข้อผิดพลาดจากกราฟสดได้ทันที ไม่มี locustfile ไม่ต้องติดตั้ง pip ไม่ต้องใช้ Python เลย
Locust ทำอะไรได้ดีจริงๆ
Locust เป็นเครื่องมือทดสอบโหลดแบบโอเพนซอร์สที่เขียนด้วย Python และมันทำได้ดีในสิ่งที่ถูกสร้างขึ้นมาเพื่อทำ คุณอธิบายพฤติกรรมผู้ใช้เป็นโค้ด ผู้ใช้เสมือนคือคลาส Python และสิ่งที่ผู้ใช้นั้นทำคือเมธอดที่คุณติดแท็กเป็นงาน (tasks) นี่คือรูปแบบมาตรฐานของ locustfile.py:
from locust import HttpUser, task, between
class CheckoutUser(HttpUser):
wait_time = between(1, 3)
@task(3)
def browse_products(self):
self.client.get("/api/products")
@task(1)
def add_to_cart(self):
self.client.post("/api/cart", json={"sku": "AK-204", "qty": 1})
คุณรันมันด้วย locust -f locustfile.py เปิดเว็บ UI ที่ localhost:8089 กำหนดจำนวนผู้ใช้และอัตราการเกิด (spawn rate) แล้วดูตัวเลขที่เพิ่มขึ้น เนื่องจากพฤติกรรมเป็นโค้ด คุณจึงได้รับพลังในการแสดงออกที่แท้จริง ไม่ว่าจะเป็นตรรกะแบบมีเงื่อนไข การกระจายงานแบบถ่วงน้ำหนัก ลำดับการเดินทางของผู้ใช้ ไคลเอนต์ที่กำหนดเองสำหรับโปรโตคอลนอกเหนือจาก HTTP สถานะที่ใช้ร่วมกันระหว่างการร้องขอ การถ่วงน้ำหนัก @task(3) เทียบกับ @task(1) ข้างต้นหมายถึงการเรียกดูเกิดขึ้นบ่อยกว่าการเพิ่มสินค้าลงในรถเข็นถึงสามเท่า ซึ่งเป็นความสมจริงที่รายการคำขอแบบเรียบๆ ไม่สามารถจับได้
Locust ยังสามารถปรับขนาดในแนวนอนได้อีกด้วย คุณสามารถรันแบบกระจายไปทั่วหลายกระบวนการทำงานหรือหลายเครื่อง และมีมาสเตอร์เพียงตัวเดียวที่ประสานงานทั้งหมด ทำให้คุณสามารถผลักดันให้เกินขีดจำกัดที่เครื่องเดียวจะสร้างขึ้นมาได้ ภายใต้การทำงานนั้น มันขับเคลื่อนด้วยเหตุการณ์ (event-driven) ดังนั้นเวิร์คเกอร์แต่ละตัวจึงสามารถรองรับผู้ใช้พร้อมกันได้หลายพันคนโดยไม่ต้องใช้เธรดต่อผู้ใช้ซึ่งจะกินหน่วยความจำ สำหรับทีมที่ใช้ Python อยู่แล้ว ถือว่าการทดสอบโหลดเป็นโค้ดที่ควบคุมเวอร์ชัน และต้องการสร้างโมเดลพฤติกรรมผู้ใช้แบบหลายขั้นตอนที่ซับซ้อน Locust เป็นตัวเลือกที่แข็งแกร่ง ไม่มีข้อโต้แย้งใดๆ ในเรื่องนี้
ค่าใช้จ่ายคือโค้ด การทดสอบทุกครั้งคือโปรแกรมที่คุณเขียน แก้ไขข้อบกพร่อง และดูแลรักษา หาก API ของคุณมีการเปลี่ยนแปลง ไฟล์ locustfile ก็ต้องเปลี่ยนตาม หากวิศวกรคนใหม่ต้องการรันการทดสอบ พวกเขาจำเป็นต้องมีสภาพแวดล้อม Python ที่ตรงกัน และหากคุณไม่ได้เขียน Python อยู่แล้ว ภาษา Python เองก็กลายเป็นข้อกำหนดเบื้องต้นในการตอบคำถามที่ไม่เกี่ยวข้องกับ Python เลย
จุดที่โมเดล Code-First กลายเป็นอุปสรรค
อุปสรรคนี้ปรากฏในสามด้าน
ประการแรกคือการตั้งค่า ก่อนที่คุณจะวัดผลอะไร คุณต้องติดตั้ง Python สร้าง virtual environment, pip install locust และเขียน harness สำหรับการตรวจสอบแบบรวดเร็วว่า "เอนด์พอยต์นี้รองรับผู้ใช้ 50 คนได้หรือไม่" นี่เป็นการทำงานเบื้องหลังมากกว่าผลลัพธ์ที่ต้องการ
ประการที่สองคือการทำซ้ำ คุณอาจมีคำขอเหล่านี้ที่ถูกกำหนดไว้ที่ใดที่หนึ่งแล้ว อาจจะอยู่ใน Postman, ในไฟล์ .http หรือใน API client ที่ทีมของคุณใช้ทุกวัน ไฟล์ locustfile จะอธิบายคำขอที่มีอยู่แล้วซ้ำอีกครั้ง รวมถึงขั้นตอนการรับรองความถูกต้อง (auth flow) เฮดเดอร์ และเนื้อหาของคำขอ ตอนนี้คุณต้องดูแลความรู้เกี่ยวกับ API เดียวกันถึงสองชุด และพวกมันก็อาจจะคลาดเคลื่อนกันได้
ประการที่สามคือผู้ที่ต้องการคำตอบ วิศวกร QA, ผู้จัดการผลิตภัณฑ์ที่กังวลเรื่องการเปิดตัว หรือนักพัฒนาฟรอนต์เอนด์ที่แค่ต้องการทราบว่า API จะรับมือกับอีเมลการตลาดได้หรือไม่ ทั้งหมดนี้ต้องการผลลัพธ์ของการทดสอบโหลด พวกเขาไม่จำเป็นต้องอ่านหรือเขียน Python เพื่อให้ได้มาซึ่งคำตอบนั้น เมื่อการทดสอบถูกจำกัดด้วยไฟล์ locustfile คำตอบก็จะถูกจำกัดด้วยทักษะเฉพาะ
หากการทดสอบโหลดของคุณต้องการตรรกะแบบแยกสาขาและไคลเอนต์โปรโตคอลที่กำหนดเองอย่างแท้จริง อุปสรรคนั้นก็คุ้มค่าที่จะจ่ายไปและ Locust ก็เป็นเครื่องมือที่เหมาะสม สำหรับกรณีทั่วไปที่ต้องการ "รันคำขอ API จริงภายใต้โหลดพร้อมกันและแสดงตัวเลขให้ฉันดู" ก็คุ้มค่าที่จะถามว่าชั้น Python นั้นให้อะไรกับคุณบ้าง
แนวทางของ Apidog: ทดสอบโหลดคำขอที่คุณมีอยู่แล้ว
Apidog เข้าสู่การทดสอบโหลดจากอีกทิศทางหนึ่ง คุณไม่จำเป็นต้องเขียนสคริปต์ที่อธิบายคำขอ คุณนำคำขอที่คุณสร้างไว้แล้วมาใช้งานภายใต้โหลด หน่วยของการทดสอบโหลดคือ สถานการณ์การทดสอบ ซึ่งเป็นเพียงชุดคำขอ API ที่เรียงลำดับพร้อมกับสภาพแวดล้อม ตัวแปร และการยืนยันที่แนบมาแล้ว หากคุณเคยใช้ Apidog เพื่อทดสอบหรือแก้ไขข้อบกพร่องของเอนด์พอยต์ คำขอนั้นก็มีอยู่แล้ว การทดสอบประสิทธิภาพจะนำกลับมาใช้ใหม่
นี่คือขั้นตอนทั้งหมด
- เปิดสถานการณ์การทดสอบที่คุณต้องการทดสอบโหลด นี่คือสถานการณ์เดียวกับที่คุณจะรันเป็นการทดสอบฟังก์ชันการทำงานปกติ โดยมีคำขอและตัวแปรสภาพแวดล้อมเดียวกัน
- เลือกที่จะรันเป็นการทดสอบประสิทธิภาพแทนการรันครั้งเดียว
- กำหนดจำนวนผู้ใช้เสมือน Apidog รองรับผู้ใช้เสมือนได้สูงสุด 100 คน โดยแต่ละคนจะวนรอบคำขอทุกรายการในสถานการณ์นั้นพร้อมกันตลอดการทดสอบ
- กำหนดระยะเวลาการทดสอบ นั่นคือระยะเวลาที่ผู้ใช้เสมือนจะวนรอบการทำงาน
- กำหนดระยะเวลาการเร่งจำนวนผู้ใช้ (ramp-up duration) หากคุณต้องการให้ผู้ใช้เพิ่มขึ้นอย่างค่อยเป็นค่อยไป ในช่วง X นาทีแรก Apidog จะนำผู้ใช้เข้าสู่ระบบทีละน้อยแทนที่จะพร้อมกันทั้งหมด หากตั้งค่าเป็น 0 ผู้ใช้เสมือนทุกคนจะเริ่มทำงานทันที
- หากสถานการณ์ของคุณเป็นแบบขับเคลื่อนด้วยข้อมูล (data-driven) ให้เลือกโหมดการจับคู่ "Random Match" หมายถึงผู้ใช้เสมือนแต่ละคนจะดึงแถวสุ่มจากข้อมูลการทดสอบของคุณในการวนรอบแต่ละครั้ง; "Sequential Match" จะไล่เรียงแถวตามลำดับ
- เริ่มการทดสอบและดูแผงควบคุมสด
กราฟจะอัปเดตแบบเรียลไทม์ สำหรับ API แต่ละรายการในสถานการณ์ คุณจะได้รับข้อมูลคำขอทั้งหมด (Total Requests) ปริมาณงานเฉลี่ย (Avg Throughput) เวลาตอบสนองเฉลี่ย (Avg Response Time) เวลาตอบสนองสูงสุดและต่ำสุด (Maximum and Minimum Response Time) และข้อผิดพลาด (Errors) เลื่อนเมาส์เหนือแผนภูมิเพื่อดูตัวเลขสำหรับช่วงเวลาที่กำหนด แท็บ "Error" จะแสดงรายละเอียดของคำขอที่ล้มเหลว เพื่อให้คุณเห็นว่าเอนด์พอยต์ใดเริ่มมีปัญหาและเมื่อใด เมื่อการรันเสร็จสิ้น แท็บ "Test Reports" จะเก็บประวัติไว้ เพื่อให้คุณสามารถเปรียบเทียบผลลัพธ์ของวันนี้กับสัปดาห์ที่แล้วหลังจากที่คุณปล่อยการเปลี่ยนแปลง
ประเด็นทั้งหมดคือ ไม่ต้องเขียน locustfile และไม่ต้องจัดการสภาพแวดล้อม Python คำขอเดียวกับที่ผ่านการทดสอบฟังก์ชันการทำงานของคุณคือคำขอที่สร้างโหลด นั่นคือความแตกต่างระหว่างการอธิบายการทดสอบโหลดกับการรันการทดสอบ Apidog เป็น แพลตฟอร์ม API แบบครบวงจร ดังนั้นการออกแบบ การแก้ไขข้อบกพร่อง การทดสอบฟังก์ชันการทำงาน และการทดสอบโหลดของเอนด์พอยต์ทั้งหมดจึงเกิดขึ้นภายใต้คำจำกัดความเดียวของเอนด์พอยต์นั้น
การเปรียบเทียบที่ชัดเจน
สมมติว่าคุณต้องการยืนยันว่าเอนด์พอยต์สำหรับการเข้าสู่ระบบสามารถรองรับผู้ใช้พร้อมกัน 100 คนเป็นเวลาสองนาที โดยมีช่วงเวลาเร่งจำนวนผู้ใช้ (ramp-up) 30 วินาที
ใน Locust คุณจะต้องเขียนคลาสผู้ใช้ที่มี task ที่ส่งข้อมูลประจำตัว จัดการโทเค็นที่ตอบกลับมา จัดเก็บไว้สำหรับการเรียกใช้ครั้งต่อๆ ไป บันทึกไฟล์ เริ่ม locust -f login_test.py เปิดเว็บ UI และป้อนผู้ใช้ 100 คน อัตราการเกิด (spawn rate) และระยะเวลาการรัน หากการจัดการโทเค็นผิดพลาด คุณจะต้องแก้ไขข้อบกพร่อง Python ก่อนที่จะแก้ไขข้อบกพร่อง API ของคุณ
ใน Apidog คุณเปิดสถานการณ์การทดสอบการเข้าสู่ระบบที่คุณสร้างไว้แล้ว เปลี่ยนเป็นโหมดการทดสอบประสิทธิภาพ พิมพ์ 100 สำหรับผู้ใช้เสมือน 2 minutes สำหรับระยะเวลา 30 seconds สำหรับการเร่งจำนวนผู้ใช้ (ramp-up) แล้วเริ่มการทดสอบ การรับรองความถูกต้องที่เคยใช้งานได้ในการทดสอบฟังก์ชันการทำงานของคุณยังคงใช้ได้ เพราะเป็นสถานการณ์เดียวกัน คุณจะอ่านเส้นโค้งเวลาตอบสนองและอัตราข้อผิดพลาดได้ทันทีที่เกิดขึ้น
ทั้งสองวิธีให้คำตอบประเภทเดียวกัน หนึ่งในนั้นขอให้คุณเขียนและดูแลรักษาโปรแกรมก่อน อีกวิธีหนึ่งใช้สิ่งที่คุณมีอยู่แล้วซ้ำ สำหรับการเดินทางของผู้ใช้ที่ซับซ้อนและจำลองด้วยโค้ด โปรแกรมนั้นก็คุ้มค่า สำหรับคำถามที่ว่า "เอนด์พอยต์ของฉันเร็วและเสถียรภายใต้โหลดหรือไม่" การนำกลับมาใช้ซ้ำจะช่วยประหยัดเวลาได้มากกว่า
ข้อจำกัดที่แท้จริงของทั้งสองด้าน
จงพิจารณาข้อดีข้อเสียอย่างชัดเจน เพราะการเลือกเครื่องมือผิดพลาดจะทำให้เสียเวลาไปทั้งวันไม่ว่าทางใดก็ทางหนึ่ง
การทดสอบประสิทธิภาพของ Apidog รองรับผู้ใช้เสมือนสูงสุด 100 คนในการรันครั้งเดียว และโหลดจะถูกสร้างขึ้นจากเครื่องของคุณที่รันแอปพลิเคชัน หากคุณต้องการจำลองผู้ใช้หลายหมื่นคนหรือสร้างโหลดจากหลายภูมิภาคพร้อมกัน นั่นอยู่นอกเหนือขอบเขตการทดสอบประสิทธิภาพในแอป และการตั้งค่าแบบกระจาย เช่น Locust workers หรือคลัสเตอร์สร้างโหลดเฉพาะทางจะเป็นทางเลือกที่เหมาะสม Apidog ยังบันทึกคำขอที่ล้มเหลวในเชิงสถิติมากกว่าการเก็บทั้งเนื้อหาคำขอและการตอบกลับสำหรับความล้มเหลวทุกครั้ง ดังนั้นการแก้ไขข้อบกพร่องเชิงลึกสำหรับคำขอที่ล้มเหลวเฉพาะเจาะจงในช่วงกลางโหลดจึงไม่ใช่จุดแข็งของมัน
ข้อแลกเปลี่ยนของ Locust คือสิ่งที่บทความนี้พูดถึงทั้งหมด พลังมาจากโค้ด และโค้ดก็คือต้นทุนที่คงที่ คุณต้องดูแลไฟล์ locustfile สำหรับแต่ละสถานการณ์ มีสภาพแวดล้อม Python ไว้ใช้งาน และยอมรับว่าใครก็ตามที่ต้องการรันการทดสอบต้องอ่าน Python เพื่อทำความเข้าใจ สำหรับจำนวนผู้ใช้เสมือนที่สูงมากและตรรกะของโปรโตคอลที่กำหนดเอง ค่าใช้จ่ายนั้นคุ้มค่าจริง สำหรับการตรวจสอบโหลด API ในชีวิตประจำวัน มันคือภาระที่มากเกินไป
กฎที่สมเหตุสมผล: หากคุณสามารถอธิบายการทดสอบได้ว่า "รันคำขอเหล่านี้พร้อมกันด้วยจำนวนเท่านี้เป็นระยะเวลานานเท่านี้" ให้เลือกใช้การทดสอบประสิทธิภาพในแอปพลิเคชัน หากคุณต้องการตรรกะแบบมีเงื่อนไข กราฟงานแบบถ่วงน้ำหนัก ไคลเอนต์ที่กำหนดเอง หรือจำนวนผู้ใช้หลักแสน ให้เลือกใช้โค้ด สำหรับภาพรวมที่กว้างขึ้นว่าแต่ละตัวเลือกเหมาะสมกับสิ่งใด โปรดดูบทสรุปของเราเกี่ยวกับ เครื่องมือทดสอบโหลดชั้นนำ และ การเปรียบเทียบเครื่องมือทดสอบโหลดเฉพาะ API
การอ่านตัวเลขที่คุณได้รับกลับมา
การทดสอบโหลดจะมีประโยชน์ก็ต่อเมื่อคุณทราบว่าผลลัพธ์หมายถึงอะไร เมตริกสี่ประการมีความสำคัญมากที่สุด
ปริมาณงาน (Throughput) (RPS/TPS) คือจำนวนคำขอหรือธุรกรรมต่อวินาที ซึ่งเป็นอัตราที่ API ของคุณให้บริการจริง มันคือขีดจำกัดสูงสุดที่ระบบของคุณสามารถรองรับได้ หากปริมาณงานคงที่ในขณะที่คุณยังคงเพิ่มผู้ใช้เสมือน คุณได้พบจุดอิ่มตัวแล้ว
เวลาตอบสนอง (latency) คือระยะเวลาที่แต่ละคำขอใช้ไป ให้ดูที่ค่าเฉลี่ย แต่ให้ดูที่ค่าสูงสุดให้ดีกว่า ค่าเฉลี่ยที่ดีแต่มีค่าสูงสุดที่แย่ หมายความว่าผู้ใช้บางรายกำลังประสบปัญหาแม้ว่าส่วนใหญ่จะปกติดี Latency ส่วนท้ายคือจุดที่ผู้ใช้จริงรู้สึกถึงปัญหา
อัตราข้อผิดพลาด (Error rate) คือสัดส่วนของคำขอที่ล้มเหลว การทดสอบที่สะอาดภายใต้โหลดต่ำที่เริ่มส่งคืนข้อผิดพลาด 500 หรือหมดเวลาเมื่อจำนวนผู้ใช้เสมือนเพิ่มขึ้น กำลังบอกคุณอย่างชัดเจนว่าระบบล่มที่จุดใด จุดที่ข้อผิดพลาดเริ่มต้นขึ้นมักจะน่าสนใจกว่าตัวเลขปริมาณงานดิบ
ความพร้อมกัน (Concurrency) คือจำนวนผู้ใช้เสมือนที่กำลังทำงานอยู่ ใน Apidog นี่คือจำนวนผู้ใช้เสมือนที่คุณกำหนด และการเร่งจำนวนผู้ใช้ (ramp-up) จะควบคุมความเร็วที่คุณไปถึงจุดนั้น การเร่งจำนวนผู้ใช้มีความสำคัญเนื่องจากระบบที่รองรับผู้ใช้ 100 คนที่ค่อยๆ เพิ่มขึ้น อาจยังคงล่มได้หากผู้ใช้ทั้ง 100 คนเข้ามาพร้อมกันในวินาทีเดียว
หากคุณต้องการข้อมูลเชิงลึกเกี่ยวกับเรื่องนี้ คู่มือของเราเกี่ยวกับการ ทดสอบประสิทธิภาพ API จะอธิบายถึงเมตริก ประเภทการทดสอบ และวิธีการอ่านกราฟ และบทความ พื้นฐานการทดสอบประสิทธิภาพ จะครอบคลุมสาขาวิชาที่กว้างขึ้น
สิ่งนี้เข้ากันได้กับเครื่องมือที่คุณเปรียบเทียบอยู่แล้วอย่างไร
หากคุณเคยใช้ JMeter โมเดลความคิดจะคล้ายกับของ Apidog เนื่องจากทั้งสองช่วยให้คุณกำหนดค่าการทดสอบโหลดผ่าน UI แทนที่จะใช้โค้ด JMeter แลกเปลี่ยนสิ่งนั้นกับแผนการทดสอบที่ใช้ XML ที่ซับซ้อนกว่าและมีช่วงการเรียนรู้ที่สูงชันกว่า; บทช่วยสอนการทดสอบโหลดด้วย JMeter ของเราครอบคลุมรายละเอียดนี้ หากคุณเคยรันโหลดผ่าน Postman’s collection runner คุณจะเห็นแนวคิดที่เบากว่าของแนวคิดเดียวกัน ซึ่งครอบคลุมอยู่ใน การทดสอบโหลดด้วย Postman และ Apidog ยังเพิ่มการรายงานประสิทธิภาพเฉพาะทางนอกเหนือจากคำขอที่คุณสามารถใช้สำหรับการ ทดสอบ API โดยไม่ต้องใช้ Postman Apidog อยู่ระหว่างความเรียบง่ายแบบไม่ต้องใช้โค้ดที่ผู้คนต้องการ และการนำคำขอกลับมาใช้ใหม่ที่ช่วยให้คุณไม่ต้องดูแล harness แยกต่างหาก
ประเด็นร่วมกันของเครื่องมือทั้งหมดคือ การทดสอบโหลดของคุณควรนำความรู้เกี่ยวกับ API ที่คุณเคยเข้ารหัสไว้กลับมาใช้ใหม่ ไม่ใช่ทำซ้ำในภาษาใหม่ Locust ทำซ้ำใน Python เพราะ Python คือจุดแข็งของมัน Apidog นำสถานการณ์ของคุณกลับมาใช้ใหม่เพราะการนำกลับมาใช้ใหม่คือจุดแข็งของมัน
เริ่มต้นใช้งาน
หากคำขอของคุณมีอยู่ใน Apidog อยู่แล้ว คุณสามารถรันการทดสอบประสิทธิภาพได้ภายในห้านาทีถัดไป เปิดสถานการณ์การทดสอบ เปลี่ยนเป็นโหมดการทดสอบประสิทธิภาพ กำหนดผู้ใช้เสมือนและระยะเวลา แล้วเริ่มการทดสอบ หากคุณมาจากไฟล์ locustfile และเบื่อกับการดูแลเลเยอร์ Python ให้สร้างสถานการณ์ขึ้นมาใหม่เพียงครั้งเดียวในแอป แล้วคุณจะไม่ต้องเขียนโค้ดทดสอบโหลดสำหรับเอนด์พอยต์นั้นอีกเลย
ดาวน์โหลด Apidog และชี้การทดสอบประสิทธิภาพไปยังเอนด์พอยต์ที่คุณทดสอบอยู่แล้ว คุณจะได้เส้นโค้งของปริมาณงาน (throughput) ความหน่วง (latency) และอัตราข้อผิดพลาด (error rate) ก่อนที่คุณจะเขียนไฟล์ locustfile ที่เทียบเท่าเสร็จ Locust ยังคงเป็นคำตอบที่ถูกต้องสำหรับโหลดที่กระจายตัวและจำลองด้วยโค้ดในระดับมหภาค สำหรับคำถามที่นักพัฒนาส่วนใหญ่ต้องการทราบจริง ๆ ให้รันคำขอที่คุณมีอยู่แล้ว
คำถามที่พบบ่อย (FAQ)
Apidog สามารถใช้แทน Locust ได้ทั้งหมดหรือไม่?
ไม่ใช่สำหรับทุกงาน สำหรับการทดสอบโหลดคำขอ API ที่มีผู้ใช้เสมือนสูงสุด 100 คนโดยไม่ต้องเขียนโค้ด Apidog สามารถแทนที่เวิร์กโฟลว์ของ Locust ทั้งหมดได้ เนื่องจากมันรันสถานการณ์การทดสอบที่มีอยู่ของคุณได้โดยตรง สำหรับโหลดแบบกระจายที่มีจำนวนผู้ใช้สูงมากหรือโปรโตคอลที่ไม่ใช่ HTTP ที่กำหนดเองและสร้างแบบจำลองด้วยโค้ด Locust ยังคงเหมาะสมกว่า
ฉันจำเป็นต้องเขียนโค้ดเพื่อทดสอบโหลดใน Apidog หรือไม่?
ไม่ คุณกำหนดค่าผู้ใช้เสมือน ระยะเวลาการทดสอบ และระยะเวลาการเร่งจำนวนผู้ใช้ (ramp-up time) ใน UI และการทดสอบจะรันคำขอจากสถานการณ์การทดสอบที่คุณสร้างไว้แล้ว ไม่ต้องมี locustfile และไม่ต้องตั้งค่าสภาพแวดล้อม Python
Apidog สามารถจำลองผู้ใช้เสมือนได้กี่คน?
สูงสุด 100 ผู้ใช้เสมือนในการทดสอบประสิทธิภาพครั้งเดียว แต่ละคนจะวนรอบ API ทุกรายการในสถานการณ์พร้อมกันตลอดระยะเวลาที่คุณกำหนด หากคุณต้องการมากกว่านั้นมากหรือโหลดจากหลายภูมิภาค เครื่องมือแบบกระจายที่ใช้โค้ดอย่าง Locust จะเป็นทางเลือกที่เหมาะสมกว่า
การทดสอบประสิทธิภาพของ Apidog รายงานเมตริกอะไรบ้าง?
สำหรับ API แต่ละรายการในสถานการณ์ คุณจะได้รับข้อมูลคำขอทั้งหมด (Total Requests) ปริมาณงานเฉลี่ย (Avg Throughput) เวลาตอบสนองเฉลี่ย (Avg Response Time) เวลาตอบสนองสูงสุดและต่ำสุด (Maximum and Minimum Response Time) และข้อผิดพลาด (Errors) ซึ่งอัปเดตแบบสดบนแผนภูมิ แท็บ Error จะแสดงรายละเอียดของคำขอที่ล้มเหลว และแท็บ Test Reports จะเก็บประวัติการรันไว้ เพื่อให้คุณสามารถเปรียบเทียบผลลัพธ์เมื่อมีการเปลี่ยนแปลงได้
ฉันสามารถทดสอบโหลดด้วยคำขอที่ขับเคลื่อนด้วยข้อมูล (data-driven) ได้หรือไม่?
ได้ หากสถานการณ์ของคุณมีข้อมูลทดสอบรองรับ ให้เลือก “Random Match” เพื่อให้ผู้ใช้เสมือนแต่ละคนดึงแถวสุ่มในการวนรอบแต่ละครั้ง หรือ “Sequential Match” เพื่อไล่เรียงแถวตามลำดับ
ฉันยังควรใช้ Locust สำหรับสิ่งใดบ้างหรือไม่?
ได้ เมื่อจุดแข็งของมันตรงกับความต้องการของคุณ: พฤติกรรมผู้ใช้ที่กำหนดด้วยโค้ดพร้อมตรรกะแบบแยกสาขาและงานแบบถ่วงน้ำหนัก ไคลเอนต์โปรโตคอลที่กำหนดเอง และการสร้างโหลดแบบกระจายที่สามารถผลักดันให้เกิน 100 ผู้ใช้เสมือนได้อย่างมาก ใช้เครื่องมือที่เหมาะสมกับลักษณะของการทดสอบ