Vegeta โหลดเทส: คู่มือสอน HTTP อัตราคงที่

คุณต้องการทราบว่า API ของคุณทำงานอย่างไรที่อัตรา 500 คำขอต่อวินาที ไม่ใช่แค่ "เร็วเท่าที่เธรด N จะส่งได้" เครื่องมือทดสอบโหลดส่วนใหญ่จะกำหนดการทำงานพร้อมกันและปล่อยให้อัตราคำขอลอยตัว แต่ Vegeta ทำตรงกันข้าม: คุณกำหนดอัตรา และมันจะส่งคำขอจำนวนนั้นต่อวินาทีโดยไม่คำนึงว่าเซิร์ฟเวอร์จะตอบสนองอย่างไร ความแตกต่างนี้มีความสำคัญเมื่อคุณสนใจตัวเลขที่อยู่ในใบคะแนน ปริมาณงานที่โหลดเป้าหมาย และเวลาแฝงที่คุณจะสามารถรับประกันได้จริงใน SLO

ปุ่ม

Vegeta คืออะไร

Vegeta คือเครื่องมือทดสอบโหลด HTTP แบบบรรทัดคำสั่งที่เขียนด้วยภาษา Go นอกจากนี้ยังสามารถใช้งานเป็นไลบรารี Go ได้ด้วย แต่บทช่วยสอนนี้จะเน้นที่ CLI แนวคิดหลักคืออัตราคำขอคงที่ คุณบอก Vegeta ว่า "ส่งคำขอ 100 คำขอต่อวินาทีเป็นเวลา 30 วินาที" และมันจะรักษาระดับนั้นโดยการเพิ่มเวิร์กเกอร์ตามความจำเป็น หากเซิร์ฟเวอร์ทำงานช้าลง Vegeta จะยังคงส่งคำขอใหม่ตามกำหนดเวลาแทนที่จะรอคำขอเก่าให้เสร็จสิ้น

การออกแบบนี้ทำให้คุณได้การทดสอบโหลดแบบเปิด (open-model load test) การรับส่งข้อมูลจริงจะมาตามเวลาของมันเอง ผู้ใช้ไม่หยุดรอปลายทางที่ช้าของคุณก่อนที่ผู้ใช้รายถัดไปจะปรากฏขึ้น เครื่องมือที่อิงตามอัตราจะตรงกับพฤติกรรมนี้

โหลดแบบอิงตามอัตราเทียบกับโหลดแบบอิงตามการทำงานพร้อมกัน

นี่คือจุดที่ผู้คนสับสน

เครื่องมือที่อิงตามการทำงานพร้อมกัน (กลุ่มเธรดหรือผู้ใช้เสมือนที่คงที่ ซึ่งแต่ละเธรด/ผู้ใช้จะวนลูปคำขอ-การตอบกลับ) ใช้แบบจำลองปิด เมื่อเซิร์ฟเวอร์ทำงานช้าลง ลูปจะหยุดชะงัก ทำให้อัตราคำขอจริงลดลง คุณขอโหลด แต่เครื่องมือกลับลดลงอย่างเงียบๆ สิ่งนี้จะซ่อนการสะสมของคำขอที่คุณจะเห็นในสภาพแวดล้อมการผลิต

เครื่องมือที่อิงตามอัตราเช่น Vegeta ใช้แบบจำลองเปิด คุณกำหนดอัตราการมาถึง หากเซิร์ฟเวอร์ไม่สามารถรองรับได้ คำขอจะถูกจัดคิว เวลาแฝงจะเพิ่มขึ้น และรายงานจะแสดงให้เห็น คุณจะได้ภาพที่ซื่อสัตย์ของสิ่งที่เกิดขึ้นเมื่อความต้องการเกินขีดความสามารถ

ไม่มีแบบจำลองใดที่ผิด ใช้การทำงานพร้อมกันเมื่อคุณต้องการทราบว่า "ฉันสามารถรองรับผู้ใช้พร้อมกันได้กี่คน" ใช้แบบจำลองอัตราเมื่อคุณต้องการทราบว่า "จะเกิดอะไรขึ้นเมื่อมีคำขอ 2,000 คำขอต่อวินาที" Vegeta เป็นแบบที่สอง สำหรับแผนผังเครื่องมือที่กว้างขึ้น ดู เครื่องมือทดสอบโหลด API ยอดนิยม

ติดตั้ง Vegeta

เลือกวิธีที่เหมาะสมกับการตั้งค่าของคุณ

Homebrew บน macOS:

brew update && brew install vegeta

ตัวจัดการแพ็คเกจอื่น ๆ:

# MacPorts
port install vegeta

# Arch Linux
pacman -S vegeta

# FreeBSD
pkg install vegeta

จากซอร์สโค้ดเมื่อติดตั้ง Go แล้ว:

git clone https://github.com/tsenart/vegeta
cd vegeta
make vegeta

คุณยังสามารถดาวน์โหลดไบนารีที่สร้างไว้ล่วงหน้าได้จากหน้าการเผยแพร่ของ GitHub ตรวจสอบการติดตั้ง:

vegeta --help

ไปป์ไลน์หลัก

Vegeta สร้างขึ้นรอบไปป์ของ Unix เป้าหมายเข้าสู่ระบบ การโจมตีดำเนินไป และรายงานจะออกมา การทำงานที่มีประโยชน์ที่เล็กที่สุดคือหนึ่งบรรทัด:

echo "GET http://localhost:8080/" | vegeta attack -duration=5s -rate=100 | vegeta report

อ่านจากซ้ายไปขวา:

echo เขียนเป้าหมายหนึ่งรายการ (เมธอดและ URL) ไปยังเอาต์พุตมาตรฐาน
vegeta attack อ่านเป้าหมายนั้นจากอินพุตมาตรฐานและส่ง 100 คำขอต่อวินาทีเป็นเวลา 5 วินาที รวมทั้งหมด 500 คำขอ
vegeta report อ่านสตรีมผลลัพธ์ไบนารีและพิมพ์สรุป

แฟล็ก -rate รับค่าคำขอต่อหน่วยเวลา -rate=100 และ -rate=100/1s มีความหมายเหมือนกัน -rate=50/500ms หมายถึง 50 คำขอทุก 500 มิลลิวินาที การตั้งค่า -rate=0 จะลบข้อจำกัดอัตราออกและส่งคำขอให้เร็วที่สุดเท่าที่จะทำได้ ซึ่งเป็นการทดสอบที่แตกต่างกันโดยสิ้นเชิง

รายงานข้อความจะมีลักษณะดังนี้:

Requests      [total, rate, throughput]  500, 100.20, 100.18
Duration      [total, attack, wait]      4.991s, 4.990s, 1.2ms
Latencies     [min, mean, 50, 90, 95, 99, max]  412us, 1.3ms, 1.1ms, 1.9ms, 2.4ms, 5.1ms, 12ms
Bytes In      [total, mean]              128500, 257.00
Bytes Out     [total, mean]              0, 0.00
Success       [ratio]                    100.00%
Status Codes  [code:count]               200:500
Error Set:

อ่านบรรทัดเวลาแฝงก่อน คอลัมน์ 50 คือค่ามัธยฐาน คอลัมน์ 99 คือส่วนท้าย: 1 เปอร์เซ็นต์ของคำขอช้ากว่าค่านี้ ส่วนท้ายคือจุดที่ผู้ใช้รู้สึกไม่พอใจ ดังนั้นค่าเฉลี่ยที่ดีแต่มีเปอร์เซ็นไทล์ที่ 99 ที่แย่ก็ยังคงเป็นปัญหา ตรวจสอบ Success [ratio] และ Status Codes ถัดไป อัตราความสำเร็จ 100 เปอร์เซ็นต์พร้อมโค้ด 200 ทั้งหมดหมายความว่าเซิร์ฟเวอร์สามารถรับโหลดได้ หากมีโค้ด 5xx หรือ Error Set ไม่ว่างเปล่า หมายความว่ามันเริ่มทำงานผิดปกติ

บันทึกผลลัพธ์แล้วรายงานได้หลายวิธี

การส่งตรงไปยัง report ก็ใช้ได้สำหรับการดูอย่างรวดเร็ว สำหรับสิ่งที่คุณจะกลับมาดูอีกครั้ง ให้บันทึกผลลัพธ์ดิบลงในไฟล์ก่อน จากนั้นสร้างรายงานที่คุณต้องการจากไฟล์นั้น

echo "GET http://localhost:8080/" | \
  vegeta attack -duration=10s -rate=200 -output=results.bin

ตอนนี้การทำงานถูกบันทึกไว้ใน results.bin สร้างรายงานข้อความ:

vegeta report results.bin

สร้าง JSON ที่มีโครงสร้างสำหรับแดชบอร์ดหรือเพื่อเปรียบเทียบระหว่างการทำงาน:

vegeta report -type=json results.bin > metrics.json

สร้างฮิสโตแกรมเวลาแฝงด้วยช่วงข้อมูลที่คุณเลือก:

vegeta report -type='hist[0,2ms,5ms,10ms,25ms,100ms]' results.bin

ฮิสโตแกรมจะนับจำนวนคำขอที่ตกอยู่ในแต่ละช่วงเวลาแฝง เป็นวิธีที่รวดเร็วในการดูว่าเวลาแฝงรวมกันอย่างหนาแน่นหรือกระจายไปในวงกว้าง

รูปแบบไฟล์เป้าหมาย

API จริงต้องการมากกว่าหนึ่งคำขอ GET ย้ายเป้าหมายของคุณไปยังไฟล์และส่งผ่านด้วย -targets รูปแบบ HTTP เริ่มต้นเป็นแบบบรรทัดต่อบรรทัดและอ่านง่าย

สร้าง targets.txt:

GET http://localhost:8080/api/users

POST http://localhost:8080/api/users
Content-Type: application/json
@./payload.json

GET http://localhost:8080/api/users/42

กฎบางประการทำให้สิ่งนี้ทำงานได้:

บรรทัดแรกของแต่ละเป้าหมายคือ METHOD URL
บรรทัดส่วนหัวตามมาโดยตรงใต้บรรทัดเมธอด โดยมี Key: Value หนึ่งคู่ต่อบรรทัด
บรรทัดที่ขึ้นต้นด้วย @ ระบุชื่อไฟล์ซึ่งเนื้อหาจะกลายเป็นเนื้อหาคำขอ
บรรทัดว่างคั่นเป้าหมายหนึ่งจากอีกเป้าหมายหนึ่ง
บรรทัดที่ขึ้นต้นด้วย # คือความคิดเห็น

ใส่เนื้อหา JSON ของคุณใน payload.json:

{ "name": "Ada", "role": "engineer" }

ทำการโจมตีกับไฟล์:

vegeta attack -targets=targets.txt -rate=50 -duration=30s | vegeta report

Vegeta จะวนรอบเป้าหมายตามลำดับและดำเนินการต่อจนกว่าจะหมดเวลา คุณยังสามารถเพิ่มส่วนหัวส่วนกลางบนบรรทัดคำสั่งด้วย -header ซึ่งสะดวกสำหรับการยืนยันตัวตน:

vegeta attack -targets=targets.txt -rate=50 -duration=30s \
  -header="Authorization: Bearer $TOKEN" | vegeta report

สำหรับการรันแบบโปรแกรมหรือปริมาณมาก Vegeta ยังอ่านรูปแบบเป้าหมาย JSON ได้ด้วย แต่ละบรรทัดคือวัตถุ JSON หนึ่งรายการ และคุณเลือกโดยใช้ -format=json:

{"method": "GET", "url": "http://localhost:8080/api/users"}
{"method": "POST", "url": "http://localhost:8080/api/users", "header": {"Content-Type": ["application/json"]}, "body": "eyJuYW1lIjoiQWRhIn0="}

ฟิลด์ body ถูกเข้ารหัสแบบ base64 รูปแบบนี้สามารถสตรีมได้ดี ดังนั้นคุณสามารถสร้างเป้าหมายได้ทันทีและส่งผ่านโดยตรงด้วย -lazy เพื่อประสิทธิภาพหน่วยความจำ

กราฟและฮิสโตแกรม

ตัวเลขเดียวอาจซ่อนแนวโน้มได้ หากเวลาแฝงแย่ลงครึ่งทางของการรัน คุณต้องการเห็นเส้นโค้ง คำสั่ง plot ของ Vegeta จะเปลี่ยนสตรีมผลลัพธ์ให้เป็นหน้า HTML แบบโต้ตอบ:

vegeta attack -targets=targets.txt -rate=100 -duration=60s | \
  vegeta plot > plot.html

เปิด plot.html ในเบราว์เซอร์ คุณจะได้แผนภูมิอนุกรมเวลาของเวลาแฝงตลอดการรัน ดังนั้นการเพิ่มขึ้นอย่างช้าๆ หรือการพุ่งขึ้นกลางการทดสอบจะเห็นได้ชัด คุณสามารถพล็อตกราฟหลายๆ ครั้งพร้อมกันเพื่อเปรียบเทียบระดับโหลดได้:

vegeta attack -rate=50  -duration=30s -targets=targets.txt -output=50qps.bin
vegeta attack -rate=100 -duration=30s -targets=targets.txt -output=100qps.bin
vegeta plot 50qps.bin 100qps.bin > compare.html

สำหรับสภาพแวดล้อมที่ไม่มีส่วนต่อประสานผู้ใช้ (headless environments) ให้ข้ามการสร้างกราฟและส่งออกฮิสโตแกรมหรือ CSV ดิบด้วย encode:

vegeta encode -to=csv results.bin > results.csv

ควรใช้ Vegeta เมื่อใด

เลือกใช้ Vegeta เมื่อคำถามเกี่ยวข้องกับอัตราและขีดความสามารถ:

คุณต้องการปริมาณงานและเวลาแฝงที่เป้าหมายคำขอต่อวินาทีที่เฉพาะเจาะจง
คุณต้องการหาอัตราที่เวลาแฝงหรืออัตราข้อผิดพลาดเริ่มเพิ่มขึ้น
คุณกำลังเปรียบเทียบสองบิลด์หรือสองการกำหนดค่าโครงสร้างพื้นฐานภายใต้โหลดที่เหมือนกันและทำซ้ำได้
คุณต้องการเครื่องมือที่เขียนสคริปต์ได้ซึ่งสามารถรวมเข้ากับไปป์ไลน์เชลล์และงาน CI ได้โดยไม่ต้องมี GUI

มันเป็นเครื่องมือที่เน้นเฉพาะกิจ มันส่งคำขอ HTTP ด้วยอัตราที่กำหนดและวัดว่าเซิร์ฟเวอร์ตอบสนองอย่างไร มันไม่ได้เขียนสคริปต์เส้นทางการใช้งานหลายขั้นตอนพร้อมตรรกะการแตกแขนง และไม่ได้ตรวจสอบความถูกต้องของเนื้อหาการตอบกลับนอกเหนือจากรหัสสถานะ การเน้นเฉพาะกิจนี้เป็นคุณสมบัติที่ทำให้เครื่องมือมีขนาดเล็กและผลลัพธ์ที่ชัดเจน

หากคุณกำลังเปรียบเทียบกับเครื่องมืออื่นๆ การเปรียบเทียบใน การทดสอบโหลดด้วย k6 และ การทดสอบโหลดด้วย JMeter จะครอบคลุมทางเลือกที่เป็นแบบจำลองการทำงานพร้อมกัน สำหรับแนวคิดพื้นฐานและเมตริก บทช่วยสอนการทดสอบประสิทธิภาพ API เป็นข้อมูลเบื้องต้นที่ดี

การทดสอบฟังก์ชันเหมาะกับตรงไหน

การทดสอบโหลดตอบคำถามว่า "เร็วพอหรือไม่" ไม่ได้ตอบคำถามว่า "ถูกต้องหรือไม่" การรัน Vegeta สามารถรายงานรหัส 200 ได้ 100 เปอร์เซ็นต์ ในขณะที่ปลายทางส่งคืนผู้ใช้ผิดคน, ราคาเก่า, หรือฟิลด์ JSON ที่ผิดรูปแบบ การตอบกลับเหล่านั้นทั้งหมดคือรหัส 200 ที่เร็วและสำเร็จ ตราบใดที่เครื่องมือโหลดมองเห็น

ความถูกต้องต้องมีการตรวจสอบที่แตกต่างกัน: การยืนยันบนเนื้อหาการตอบกลับ, สคีมา และกฎทางธุรกิจ นั่นคือ การทดสอบฟังก์ชัน และมันควรอยู่ก่อนและควบคู่ไปกับการทดสอบโหลดของคุณ รูปแบบที่ดีคือการตรวจสอบว่า API ถูกต้อง จากนั้นวัดประสิทธิภาพภายใต้อัตราที่กำหนด

นี่คือจุดที่ Apidog เข้ามาเสริมเครื่องมืออย่าง Vegeta มากกว่าที่จะแข่งขันกัน ใน Apidog คุณสร้างสถานการณ์การทดสอบด้วยการยืนยันแบบภาพ (visual assertions) บนสถานะ, ส่วนหัว, และฟิลด์ JSON, เชื่อมโยงคำขอ และขับเคลื่อนด้วยไฟล์ข้อมูล คุณยืนยันว่า API ส่งคืนข้อมูลที่ถูกต้อง จากนั้น Vegeta จะยืนยันว่ามันยังคงรวดเร็วเมื่อเส้นทางที่ถูกต้องนั้นถูกเรียกใช้หลายร้อยครั้งต่อวินาที สองเครื่องมือ สองคำถาม

Apidog ยังมาพร้อมกับ CLI แบบ headless เพื่อให้สถานการณ์การทำงานเหล่านั้นสามารถรันได้ในไปป์ไลน์ CI เดียวกันกับขั้นตอนการโหลดของคุณ ติดตั้งด้วย Node:

npm install -g apidog-cli

จากนั้นรันสถานการณ์หรือชุดทดสอบที่บันทึกไว้ด้วย ID พร้อมกับรายงานสำหรับไปป์ไลน์ของคุณ:

apidog run --access-token "$APIDOG_ACCESS_TOKEN" \
  -t <scenarioOrSuiteId> \
  -e <environmentId> \
  -r cli,html,junit

แฟล็ก -t ใช้ ID สถานการณ์, โฟลเดอร์ หรือชุดทดสอบ, -e ใช้ ID สภาพแวดล้อม และ -r เลือกหนึ่งหรือหลายรายงาน (cli, html, json, junit) เอาต์พุต junit สามารถใช้ได้กับแดชบอร์ด CI ส่วนใหญ่ ดู บทช่วยสอนบรรทัดคำสั่ง Apidog CLI สำหรับการรันทีละขั้นตอน และ คู่มือไปป์ไลน์ CI/CD สำหรับเวิร์กโฟลว์แบบคัดลอกและวาง เรียกใช้การตรวจสอบฟังก์ชันก่อน จากนั้นให้ Vegeta วัดปลายทางที่ผ่านการตรวจสอบแล้ว

คำถามที่พบบ่อย

Vegeta รองรับคำขอ POST ที่มีเนื้อหาหรือไม่?

รองรับ ในไฟล์เป้าหมาย HTTP ให้ใส่เมธอดและ URL บนบรรทัดแรก เพิ่มส่วนหัว Content-Type และอ้างอิงไฟล์เนื้อหาด้วย @./payload.json ในรูปแบบ JSON ให้ตั้งค่าฟิลด์ method, url และฟิลด์ body ที่เข้ารหัสแบบ base64

-rate=0 ทำอะไร?

มันจะลบการจำกัดอัตราและส่งคำขอให้เร็วที่สุดเท่าที่เวิร์กเกอร์และการเชื่อมต่อจะอนุญาต นั่นคือการทดสอบปริมาณงานสูงสุด ซึ่งแตกต่างจากการทดสอบอัตราคงที่ที่มีการควบคุม สำหรับการวัดขีดความสามารถที่ทำซ้ำได้ ให้กำหนดอัตราที่ชัดเจน

ฉันจะอ่านเปอร์เซ็นไทล์เวลาแฝงได้อย่างไร?

บรรทัดเวลาแฝงของรายงานจะแสดงค่าต่ำสุด, ค่าเฉลี่ย, และเปอร์เซ็นไทล์ที่ 50, 90, 95, 99, และสูงสุด ให้ความสำคัญกับเปอร์เซ็นไทล์ที่ 95 และ 99 สิ่งเหล่านี้อธิบายถึงส่วนท้ายที่ช้าที่ผู้ใช้จริงจะพบเจอ ซึ่งค่าเฉลี่ยเพียงอย่างเดียวอาจซ่อนไว้ได้

Vegeta สามารถตรวจสอบได้ว่า API ของฉันส่งคืนข้อมูลที่ถูกต้องหรือไม่?

ไม่ Vegeta วัดปริมาณงาน, เวลาแฝง, และรหัสสถานะ มันไม่ได้ยืนยันเนื้อหาการตอบกลับหรือสคีมา ใช้ร่วมกับเครื่องมือทดสอบฟังก์ชันเพื่อความถูกต้อง จากนั้นใช้ Vegeta สำหรับอัตราและเวลาแฝง

ฉันจะรัน Vegeta ใน CI ได้อย่างไร?

มันเป็นไบนารีเดียวที่อ่านอินพุตมาตรฐานและเขียนผลลัพธ์ ดังนั้นมันจึงสามารถใช้ได้กับขั้นตอนเชลล์ใดก็ได้ บันทึกผลลัพธ์ด้วย -output จากนั้นสร้างรายงานข้อความหรือ JSON เป็นสิ่งประดิษฐ์บิลด์ เพิ่มการตรวจสอบฟังก์ชัน เช่น Apidog CLI ก่อนขั้นตอนการโหลด เพื่อให้คุณวัดเฉพาะปลายทางที่ผ่านการยืนยันแล้วเท่านั้น