หาก API ของคุณทำงานได้ดีสำหรับผู้ใช้คนเดียว แต่ล้มเหลวเมื่อมีทราฟฟิก คุณจำเป็นต้องทดสอบโหลด และ k6 เป็นหนึ่งในวิธีที่ง่ายและสะอาดที่สุดในการทำเช่นนั้น คู่มือนี้จะกล่าวถึง k6 คืออะไร วิธีติดตั้ง วิธีเขียนสคริปต์แรกของคุณ และวิธีอ่านผลลัพธ์ เพื่อให้คุณสามารถนำการทดสอบโหลดไปใช้เป็นส่วนหนึ่งของกิจวัตรการทดสอบประสิทธิภาพ API ตามปกติของคุณได้ เราจะมาดูกันว่า k6 เข้ากันกับการทดสอบการทำงานใน CI ได้อย่างไร โดยอ้างอิงจาก เอกสาร k6 อย่างเป็นทางการในส่วนที่มีรายละเอียดสำคัญ
k6 คืออะไร?
k6 เป็นเครื่องมือทดสอบโหลดแบบโอเพนซอร์ส ซึ่งปัจจุบันดูแลโดย Grafana คุณเขียนการทดสอบของคุณเป็นไฟล์ JavaScript โดย k6 จะรันด้วยเอนจิน Go ที่รวดเร็ว และจะส่งทราฟฟิกจำลองไปยังปลายทางของคุณ การแบ่งแยกนี้เป็นไปโดยตั้งใจ: คุณสร้างการทดสอบด้วยภาษาที่นักพัฒนาส่วนใหญ่รู้จักอยู่แล้ว แต่ตัวสร้างโหลดเองทำงานเป็น Go ที่คอมไพล์แล้ว ทำให้เครื่องเดียวสามารถขับเคลื่อนผู้ใช้เสมือนจำนวนมากได้โดยไม่ติดขัด
k6 ถูกสร้างขึ้นมาเพื่องานเดียวและทำได้ดี: สร้างโหลดที่ต่อเนื่องและทำซ้ำได้ และวัดว่าระบบของคุณตอบสนองอย่างไร โดยจะรายงานเปอร์เซ็นไทล์ของความหน่วง, อัตราการร้องขอ, อัตราข้อผิดพลาด และช่วยให้คุณกำหนดกฎการผ่าน/ไม่ผ่านจากตัวเลขเหล่านั้น จุดเน้นนั้นสำคัญ k6 ไม่ใช่ไคลเอนต์ API, เครื่องมือเอกสารประกอบ หรือเฟรมเวิร์กทดสอบฟังก์ชันการทำงาน มันคือเอนจินสำหรับสร้างโหลด
คำศัพท์บางคำที่คุณจะพบเจออยู่เสมอ:
- ผู้ใช้เสมือน (VU): ผู้ใช้จำลองที่รันสคริปต์ของคุณซ้ำๆ ยิ่งมี VU มากเท่าไร ก็ยิ่งมีโหลดพร้อมกันมากขึ้นเท่านั้น
- รอบ (Iteration): การทำงานครบหนึ่งรอบของฟังก์ชันทดสอบของคุณ VU จะรันรอบต่างๆ ต่อเนื่องกัน
- ช่วง (Stage): ขั้นตอนในโปรไฟล์โหลด ใช้เพื่อเพิ่มหรือลดจำนวน VU ตามเวลา
- เกณฑ์ (Threshold): กฎการผ่าน/ไม่ผ่านสำหรับเมตริก เช่น "ความหน่วงที่เปอร์เซ็นไทล์ที่ 95 ต้องไม่เกิน 500 มิลลิวินาที"
- การตรวจสอบ (Check): การยืนยันที่ไม่ร้ายแรงต่อการตอบสนอง เช่น "สถานะคือ 200" การตรวจสอบที่ล้มเหลวจะถูกนับ แต่การทดสอบยังคงดำเนินต่อไป
การติดตั้ง k6
k6 มาในรูปแบบไบนารีเดียว ดังนั้นการติดตั้งจึงรวดเร็ว บน macOS ด้วย Homebrew:
brew install k6
บน Windows ด้วย Chocolatey:
choco install k6
บน Debian หรือ Ubuntu เพิ่มที่เก็บ apt ของ Grafana และติดตั้ง:
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg \
--keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" \
| sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6
ยืนยันว่าใช้งานได้:
k6 version
ยังมี Docker image ให้ใช้งานด้วย หากคุณไม่ต้องการติดตั้งอะไรในเครื่อง ตรวจสอบหน้าการติดตั้งในเอกสารสำหรับคำสั่งปัจจุบัน เนื่องจากรายละเอียดแพ็กเกจอาจมีการเปลี่ยนแปลงเมื่อเวลาผ่านไป
สคริปต์ k6 แรกของคุณ
การทดสอบ k6 คือโมดูล JavaScript ที่มีฟังก์ชันเริ่มต้น k6 จะเรียกฟังก์ชันนั้นหนึ่งครั้งต่อหนึ่งรอบ ต่อหนึ่ง VU นี่คือสคริปต์ขั้นต่ำที่ส่งคำขอไปยังปลายทางหนึ่งและตรวจสอบการตอบกลับ:
import http from 'k6/http';
import { check, sleep } from 'k6';
export default function () {
const res = http.get('https://test-api.example.com/users');
check(res, {
'status is 200': (r) => r.status === 200,
'body is not empty': (r) => r.body.length > 0,
});
sleep(1);
}
บันทึกเป็น script.js และรัน:
k6 run script.js
โดยค่าเริ่มต้น k6 จะรัน VU หนึ่งตัวสำหรับหนึ่งรอบ `sleep(1)` นั้นจะเพิ่มการหยุดชั่วคราวหนึ่งวินาทีระหว่างรอบ ซึ่งเลียนแบบผู้ใช้จริงที่หยุดพักระหว่างการกระทำต่างๆ หากไม่มี sleep แต่ละ VU จะวนซ้ำเร็วที่สุดเท่าที่เครือข่ายจะทำได้ ซึ่งมีประโยชน์สำหรับการทดสอบ throughput แบบดิบ แต่ไม่สมจริงสำหรับการจำลองพฤติกรรมผู้ใช้
การเรียกใช้ `check()` คือการยืนยันแบบไม่รุนแรง การตรวจสอบที่ล้มเหลวจะแสดงในสรุปแต่ไม่หยุดการทำงาน นี่คือเจตนา ภายใต้โหลดหนัก คุณคาดหวังว่าจะมีความล้มเหลวบ้าง และคุณต้องการให้การทดสอบวัดผลต่อไป เพื่อให้คุณเห็นว่าสถานการณ์เลวร้ายแค่ไหน
VUs, ช่วงเวลา (stages) และเกณฑ์ (thresholds)
สคริปต์แรกจะรันผู้ใช้คนเดียวหนึ่งครั้ง การทดสอบโหลดจริงคือการควบคุมจำนวนผู้ใช้ที่ส่งคำขอไปยัง API ของคุณและเป็นระยะเวลานานเท่าใด คุณกำหนดค่านี้ด้วยออบเจกต์ `options` ที่ส่งออก
รูปแบบที่ง่ายที่สุดคือกำหนดจำนวน VUs และระยะเวลาที่แน่นอน:
export const options = {
vus: 50,
duration: '30s',
};
นั่นคือการรันผู้ใช้เสมือน 50 คนเป็นเวลา 30 วินาที โปรไฟล์การเพิ่ม/ลดโหลดที่สร้างจากช่วงเวลา (stages) นั้นมีประโยชน์มากกว่า ซึ่งช่วยให้คุณจำลองการเพิ่มขึ้น การคงอยู่ และการลดลงของทราฟฟิกได้:
export const options = {
stages: [
{ duration: '1m', target: 100 }, // ramp up to 100 VUs
{ duration: '3m', target: 100 }, // hold at 100 VUs
{ duration: '1m', target: 0 }, // ramp down to 0
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% of requests under 500ms
http_req_failed: ['rate<0.01'], // less than 1% errors
},
};
เกณฑ์ (Thresholds) คือจุดที่ k6 มีบทบาทสำคัญใน CI หากเกณฑ์ล้มเหลว k6 จะออกด้วยรหัสที่ไม่ใช่ศูนย์ ซึ่งหมายความว่าขั้นตอนใน pipeline สามารถทำให้การ build ล้มเหลวได้เมื่อความหน่วงหรืออัตราข้อผิดพลาดเกินกว่าที่คุณกำหนดไว้ คุณกำลังกำหนดงบประมาณประสิทธิภาพเป็นโค้ดในลักษณะเดียวกับการกำหนดการยืนยันฟังก์ชันการทำงาน
แผนที่สรุปโปรไฟล์โหลดทั่วไปและคำถามที่แต่ละโปรไฟล์ตอบได้:
| โปรไฟล์ | เป้าหมาย | สิ่งที่บอกคุณ |
|---|---|---|
| Smoke | โหลดน้อย, ตรวจสอบว่าสคริปต์ทำงานได้ | การทดสอบนั้นถูกต้อง |
| Load | ทราฟฟิกปกติที่คาดไว้ | API สามารถรองรับการใช้งานในแต่ละวันได้หรือไม่ |
| Stress | ผลักดันเกินจุดสูงสุดที่คาดไว้ | มันเริ่มพังตรงไหน |
| Spike | จำนวน VU เพิ่มขึ้นอย่างรวดเร็วและกระทันหัน | มันสามารถรอดพ้นจากทราฟฟิกที่พุ่งสูงขึ้นได้หรือไม่ |
| Soak | โหลดปานกลางเป็นเวลาหลายชั่วโมง | หน่วยความจำรั่วไหล, ประสิทธิภาพลดลงอย่างช้าๆ |
คุณไม่จำเป็นต้องใช้ทั้งห้าแบบ เริ่มต้นด้วย smoke และ load ก่อน เพิ่ม stress และ spike เมื่อคุณทราบตัวเลขปกติของคุณแล้ว สำหรับการสำรวจแนวทางและเมตริกเบื้องหลังในวงกว้างยิ่งขึ้น พื้นฐานการทดสอบประสิทธิภาพ นั้นใช้ได้กับทุกเครื่องมือ ไม่ใช่แค่ k6 เท่านั้น
การอ่านผลลัพธ์ k6
เมื่อการรันเสร็จสิ้น k6 จะพิมพ์สรุปไปยังเทอร์มินัล บรรทัดที่สำคัญที่สุดคือ:
- http_req_duration: เวลารวมในการร้องขอ แสดงเป็นค่าเฉลี่ย, ต่ำสุด, สูงสุด, มัธยฐาน, p90 และ p95 เปอร์เซ็นไทล์ที่ p95 และ p99 จะบอกคุณถึงสิ่งที่ผู้ใช้ที่ช้าที่สุดของคุณได้รับประสบการณ์จริง ค่าเฉลี่ยซ่อนปัญหา; เปอร์เซ็นไทล์เผยให้เห็น
- http_req_failed: สัดส่วนของการร้องขอที่ล้มเหลว สังเกตว่าสิ่งนี้เปลี่ยนแปลงอย่างไรเมื่อ VUs เพิ่มขึ้น
- http_reqs: จำนวนการร้องขอทั้งหมดและการร้องขอต่อวินาที นี่คือปริมาณงานของคุณ
- iterations: จำนวนรอบที่สมบูรณ์ที่เสร็จสิ้นและอัตรา
- vus และ vus_max: ผู้ใช้เสมือนที่ใช้งานอยู่และสูงสุด
- checks: อัตราการผ่านของการยืนยัน `check()` ของคุณ
อ่านค่าเปอร์เซ็นไทล์ ไม่ใช่ค่าเฉลี่ย เวลาตอบสนองเฉลี่ย 200 มิลลิวินาทีอาจฟังดูดี จนกระทั่งคุณเห็น p99 ที่ 4 วินาที ซึ่งหมายความว่าผู้ใช้หนึ่งในร้อยคนต้องรอสี่วินาที ส่วนท้ายนั้นคือจุดที่ผู้ใช้เลิกใช้งาน
สำหรับข้อมูลที่มากกว่าการมองด้วยตาเปล่าจากเทอร์มินัล k6 สามารถสตรีมผลลัพธ์ไปยังเอาต์พุตภายนอกได้ สามารถเขียนเป็น JSON หรือ CSV และผสานรวมกับแดชบอร์ด Grafana และ Prometheus สำหรับการวิเคราะห์แบบเรียลไทม์ด้วยภาพระหว่างการรัน การจับคู่ระหว่าง k6 และ Grafana นี้คือเหตุผลที่คุณมักจะเห็นเครื่องมือนี้ถูกเรียกว่า "grafana k6" สำหรับการทดสอบครั้งเดียว สรุปในเทอร์มินัลก็เพียงพอแล้ว; สำหรับการตรวจสอบอย่างต่อเนื่อง ควรส่งเมตริกไปยังที่ที่คุณสามารถสร้างกราฟได้
k6 เหมาะสมกับที่ใด และ Apidog เหมาะสมกับที่ใด
k6 คือเอนจินโหลด มันตอบคำถามว่า "ระบบของฉันมีพฤติกรรมอย่างไรภายใต้ทราฟฟิกที่ต่อเนื่อง" มันไม่ได้ตรวจสอบว่า API ของคุณส่งคืนข้อมูลที่ถูกต้องตรงตามข้อตกลง หรือจัดการการรับรองความถูกต้องอย่างถูกต้องในทุกๆ ปลายทางหรือไม่ คำถามเหล่านั้นเป็นเรื่องของการทดสอบฟังก์ชันการทำงานและสัญญา ซึ่งต้องใช้เครื่องมือที่แตกต่างกัน
นี่คือการแบ่งแยกที่ควรทำความเข้าใจให้ชัดเจน คุณต้องการการทดสอบทั้งสองประเภทใน pipeline ของคุณ และพวกมันไม่ได้แข่งขันกัน:
| ข้อกังวล | จัดการได้ดีที่สุดโดย | สิ่งที่ตอบได้ |
|---|---|---|
| โหลดหนักต่อเนื่อง, เปอร์เซ็นไทล์ในระดับใหญ่ | k6 | มันยังคงเร็วภายใต้ทราฟฟิกหรือไม่ |
| ความถูกต้องของฟังก์ชันการทำงาน, สัญญา, การรับรองความถูกต้อง | Apidog | มันคืนค่าที่ถูกต้องหรือไม่ |
| การถดถอยใน CI ทุกครั้งที่คอมมิต | Apidog (apidog run) |
การเปลี่ยนแปลงนี้ทำให้ปลายทางเสียหรือไม่ |
| งบประมาณประสิทธิภาพใน CI | เกณฑ์ k6 | ความหน่วงหรือข้อผิดพลาดเกินขีดจำกัดหรือไม่ |
Apidog จัดการด้านความถูกต้อง คุณออกแบบหรือนำเข้า API ของคุณ สร้างสถานการณ์ทดสอบด้วยการยืนยันด้วยภาพ และรันใน CI ด้วย `apidog run` ในลักษณะเดียวกับการรันสคริปต์ k6 คู่มือ Apidog CLI จะอธิบายวิธีการเชื่อมโยงการทดสอบฟังก์ชันเหล่านั้นเข้ากับ pipeline Apidog ยังมีคุณสมบัติการทดสอบประสิทธิภาพที่เบากว่าสำหรับการตรวจสอบอย่างรวดเร็ว ซึ่งครอบคลุมในบทแนะนำการทดสอบประสิทธิภาพ API ใน Apidog แต่ก็ไม่ใช่ตัวสร้างโหลดระดับ k6 และไม่ได้พยายามที่จะเป็นเช่นนั้น
ขั้นตอนการทำงานจริงจะมีลักษณะดังนี้: ทุกครั้งที่คอมมิต Apidog จะรันการทดสอบฟังก์ชันและการทดสอบสัญญาของคุณเพื่อยืนยันว่า API ยังคงทำงานได้ตามที่ควรจะเป็น ตามกำหนดเวลาหรือก่อนการเผยแพร่ k6 จะรันโปรไฟล์โหลดกับสภาพแวดล้อม staging เพื่อยืนยันว่า API ยังคงทำงานได้รวดเร็วภายใต้ทราฟฟิก ประตูตรวจสอบความถูกต้องและประตูตรวจสอบประสิทธิภาพ แต่ละอย่างใช้เครื่องมือที่สร้างมาเพื่อสิ่งนั้น
หากคุณกำลังเปรียบเทียบเอนจินก่อนตัดสินใจ k6 จะอยู่ข้างๆ JMeter, Gatling และ Locust สรุปเครื่องมือทดสอบโหลด และการเปรียบเทียบทางเลือกของ Locust นี้จะแสดงข้อดีข้อเสีย หากภาษาที่ใช้เขียนสคริปต์หรือขนาดของการทดสอบเป็นปัจจัยในการเลือกของคุณ
คำถามที่พบบ่อย
k6 ฟรีหรือไม่?
ใช่ k6 เป็นโอเพนซอร์สภายใต้ใบอนุญาต AGPL และไบนารีสามารถรันได้ฟรีในเครื่องโดยไม่มีการจำกัดจำนวนผู้ใช้เสมือนเกินกว่าขีดจำกัดของฮาร์ดแวร์ของคุณ Grafana ยังมี k6 Cloud ซึ่งเป็นบริการแบบชำระเงินสำหรับการรันการทดสอบแบบกระจายขนาดใหญ่และจัดเก็บผลลัพธ์ แต่คุณไม่จำเป็นต้องใช้มัน เครื่องมือหลักครอบคลุมทีมส่วนใหญ่ หากคุณต้องการสำรวจตัวเลือกฟรีอื่นๆ ก่อน ภาพรวมเครื่องมือทดสอบโหลด จะแสดงรายการสิ่งที่แต่ละเครื่องมือมีให้
ฉันต้องรู้ JavaScript เพื่อใช้ k6 หรือไม่?
คุณต้องมีความรู้ JavaScript พื้นฐาน ไม่ใช่ความเชี่ยวชาญเชิงลึก สคริปต์ k6 ส่วนใหญ่ประกอบด้วยฟังก์ชันเริ่มต้น การเรียกใช้ `http.get` หรือ `http.post` บางส่วน การตรวจสอบไม่กี่อย่าง และออบเจกต์ options หากคุณสามารถอ่านตัวอย่างในคู่มือนี้ได้ คุณก็สามารถเขียนการทดสอบที่ใช้งานได้ ไม่มีขั้นตอนการ build และไม่มีเฟรมเวิร์กที่ต้องเรียนรู้ มีเพียง API ของ k6 เท่านั้น
ความแตกต่างระหว่าง k6 และ Apidog สำหรับการทดสอบประสิทธิภาพคืออะไร?
k6 เป็นตัวสร้างโหลดโดยเฉพาะที่สร้างขึ้นเพื่อขับเคลื่อนทราฟฟิกหนักที่ต่อเนื่องและรายงานเปอร์เซ็นไทล์ในระดับใหญ่ Apidog เป็นแพลตฟอร์ม API ที่เน้นการออกแบบ การทดสอบฟังก์ชันการทำงาน และการทดสอบสัญญา โดยมีคุณสมบัติการทดสอบประสิทธิภาพที่เบากว่าสำหรับการตรวจสอบอย่างรวดเร็ว ใช้ k6 เมื่อคุณต้องการโหลดจริงและงบประมาณประสิทธิภาพของ CI ใช้ Apidog สำหรับความถูกต้อง การตรวจสอบสัญญา และการรันการทดสอบฟังก์ชันการทำงานในทุกๆ คอมมิต พวกมันแก้ปัญหาที่แตกต่างกันและทำงานร่วมกันได้ดี
ฉันสามารถรัน k6 ใน CI/CD ได้หรือไม่?
ได้ และนี่คือการตั้งค่าที่พบได้บ่อย k6 จะออกด้วยรหัสที่ไม่ใช่ศูนย์เมื่อเกณฑ์ล้มเหลว ดังนั้นระบบ CI ใดๆ ก็สามารถทำให้การ build ล้มเหลวได้เมื่อเกิดการถดถอยของประสิทธิภาพ รัน `k6 run script.js` เป็นขั้นตอนใน pipeline ชี้ไปยังสภาพแวดล้อม staging และตั้งเกณฑ์สำหรับความหน่วง p95 และอัตราข้อผิดพลาด จับคู่กับการทดสอบฟังก์ชันการทำงานจาก `apidog run` เพื่อให้แต่ละคอมมิตได้รับการตรวจสอบทั้งความถูกต้องและการตรวจสอบโหลด
บทสรุป
k6 มอบวิธีที่สะอาดและสามารถเขียนสคริปต์ได้ เพื่อสร้างโหลดจริงบน API ของคุณและวัดสิ่งที่เกิดขึ้น ติดตั้งไบนารี เขียนไฟล์ JavaScript สั้นๆ กำหนด VUs และ stages เพิ่ม thresholds และอ่านค่าเปอร์เซ็นไทล์ นั่นคือวงจรทั้งหมด แยกการทดสอบโหลดออกจากการทดสอบฟังก์ชันการทำงาน เนื่องจากแต่ละอย่างตอบคำถามที่แตกต่างกัน และรันทั้งสองอย่างใน CI เพื่อไม่ให้มีสิ่งใดหลุดรอดไป
สำหรับด้านความถูกต้องของการแบ่งแยกนั้น Apidog ช่วยให้คุณออกแบบ ทดสอบ จำลอง และจัดทำเอกสาร API ของคุณได้ในที่เดียว จากนั้นรันการทดสอบฟังก์ชันการทำงานใน CI ด้วย `apidog run` ดาวน์โหลด Apidog เพื่อเพิ่มความมั่นใจในระดับสัญญาพร้อมกับการรันโหลด k6 ของคุณ