ทดสอบประสิทธิภาพ API: คู่มือฉบับสมบูรณ์

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

คู่มือนี้จะอธิบายว่าการทดสอบประสิทธิภาพ API คืออะไร ประเภทของการทดสอบที่สำคัญ เมตริกที่ควรจับตาดู และวิธีดำเนินการทดสอบประสิทธิภาพทีละขั้นตอนใน Apidog

การทดสอบประสิทธิภาพ API คืออะไร

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

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

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

ประเภทของการทดสอบประสิทธิภาพ

“การทดสอบประสิทธิภาพ” เป็นคำที่ครอบคลุม ภายใต้คำนี้มีประเภทของการทดสอบหลายแบบ ซึ่งแต่ละแบบจะตอบคำถามที่แตกต่างกัน

การทดสอบโหลด (Load testing) จำลองปริมาณการใช้งานที่คุณคาดหวัง ปริมาณคำขอปกติและสูงสุด และยืนยันว่า API สามารถรองรับได้ภายในเวลาตอบสนองที่ยอมรับได้ นี่คือการทดสอบพื้นฐานที่ทีมส่วนใหญ่ดำเนินการเป็นอันดับแรก

การทดสอบความเค้น (Stress testing) ผลักดันปริมาณการใช้งานเกินกว่าที่คาดไว้ เพิ่มโหลดจนกระทั่ง API เสื่อมสภาพหรือล้มเหลว จุดประสงค์คือเพื่อค้นหาจุดที่ระบบพังทลายและดูว่ามันพังทลาย อย่างไร มันช้าลงอย่างค่อยเป็นค่อยไป หรือส่งคืนข้อผิดพลาดและสูญเสียข้อมูลไป?

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

การทดสอบความทนทาน (Soak testing) หรือที่เรียกว่า Endurance testing จะคงโหลดปานกลางเป็นระยะเวลานานหลายชั่วโมงหรือหลายวัน เพื่อเปิดเผยปัญหาที่เกิดขึ้นช้าๆ เช่น หน่วยความจำรั่ว การหมดของ Connection Pool หรือไฟล์บันทึกที่เติมเต็มดิสก์ ปัญหาเหล่านี้จะไม่ปรากฏในการทดสอบโหลดเพียงห้านาที

การทดสอบสโมค (Smoke testing) คือการตรวจสอบเบื้องต้นแบบเบาๆ: โหลดเล็กน้อยเพื่อยืนยันว่า API และการตั้งค่าการทดสอบทำงานได้ ก่อนที่คุณจะดำเนินการทดสอบที่ใช้เวลานานและมีค่าใช้จ่ายสูง

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

เมตริกที่สำคัญ

การทดสอบประสิทธิภาพจะสร้างตัวเลขขึ้นมา นี่คือตัวเลขที่ควรพิจารณา

เวลาตอบสนอง (Response time) คือระยะเวลาที่ API ใช้ในการรับ ประมวลผล และส่งคืนคำขอ ให้ดูที่เปอร์เซ็นไทล์ ไม่ใช่แค่ค่าเฉลี่ย ค่าเฉลี่ยอาจดูดีในขณะที่เปอร์เซ็นไทล์ที่ 95 และ 99 ซึ่งเป็น 5% และ 1% ของคำขอที่ช้าที่สุดนั้นไม่เป็นที่ยอมรับ ผู้ใช้จริงจะสัมผัสได้ถึงช่วงที่ช้าที่สุด

ปริมาณงาน (Throughput) คือจำนวนคำขอที่ API ประมวลผลสำเร็จต่อวินาที มันบอกคุณถึงขีดความสามารถที่แท้จริงของระบบ โดยไม่ขึ้นอยู่กับจำนวนผู้ใช้ที่เชื่อมต่ออยู่

ผู้ใช้พร้อมกัน (Concurrent users) หรือผู้ใช้เสมือน คือจำนวนผู้เรียกใช้พร้อมกันที่การทดสอบจำลองขึ้นมา ขีดความสามารถมักจะแสดงเป็นจำนวนผู้ใช้พร้อมกันสูงสุดที่ API สามารถรองรับได้ ก่อนที่เวลาตอบสนองจะเกินงบประมาณที่คุณกำหนด

อัตราข้อผิดพลาด (Error rate) คือเปอร์เซ็นต์ของคำขอที่ล้มเหลวภายใต้ภาระ API ที่ยังคงรวดเร็วแต่เริ่มส่งคืนข้อผิดพลาด 500 เมื่อมีผู้ใช้พร้อมกันจำนวนมาก ก็ยังถือว่าสอบไม่ผ่าน

การใช้ทรัพยากร (Resource utilization) เช่น CPU และหน่วยความจำบนเซิร์ฟเวอร์ จะบอกคุณว่า ทำไม ประสิทธิภาพจึงลดลง หากเวลาตอบสนองเพิ่มขึ้นในขณะที่ CPU ทำงาน 100% แสดงว่าคุณติดขัดที่การประมวลผล หาก CPU ว่างแต่เวลาแฝงเพิ่มขึ้น คอขวดจะอยู่ที่อื่น ซึ่งมักจะเป็นฐานข้อมูลหรือการเรียกใช้บริการปลายทาง

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

วิธีดำเนินการทดสอบประสิทธิภาพ API ใน Apidog

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

ขั้นตอนที่ 1: เลือก Endpoint หรือ Scenario ที่จะทดสอบ เลือก Endpoint สำคัญเพียงจุดเดียว หรือ Scenario การทดสอบ แบบหลายขั้นตอนที่เลียนแบบการใช้งานจริงของผู้ใช้ เช่น การเข้าสู่ระบบตามด้วยการดึงข้อมูล การทดสอบการใช้งานจริงจะให้ตัวเลขที่แม่นยำกว่าการทดสอบ Endpoint เพียงจุดเดียวแยกต่างหาก

ขั้นตอนที่ 2: ยืนยันว่าผ่านการทดสอบฟังก์ชันการทำงานก่อน เรียกใช้คำขอพร้อมกับ assertions ของมันหนึ่งครั้ง ไม่มีประโยชน์ในการทดสอบโหลด Endpoint ที่ส่งคืนข้อมูลผิดพลาด แก้ไขความถูกต้องก่อนวัดความเร็ว

ขั้นตอนที่ 3: กำหนดค่าโหลด กำหนดจำนวนผู้ใช้เสมือนและระยะเวลาการทดสอบ Apidog ช่วยให้คุณเพิ่มโหลดได้อย่างค่อยเป็นค่อยไป โดยจำลองผู้ใช้ที่เข้าร่วมเมื่อเวลาผ่านไป แทนที่จะเข้าพร้อมกันทั้งหมด ซึ่งจะให้ภาพที่เป็นจริงมากขึ้นและช่วยระบุระดับการทำงานพร้อมกันที่ประสิทธิภาพเปลี่ยนแปลง

ขั้นตอนที่ 4: ดำเนินการทดสอบ Apidog จะดำเนินการโหลดและรายงานผลแบบเรียลไทม์: เวลาตอบสนอง ปริมาณงาน อัตราข้อผิดพลาด และการเปลี่ยนแปลงของแต่ละเมตริกเมื่อจำนวนผู้ใช้พร้อมกันเพิ่มขึ้น สังเกตจุดเปลี่ยนที่เวลาตอบสนองเริ่มเพิ่มขึ้นเร็วกว่าโหลด

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

ขั้นตอนที่ 6: สำหรับความต้องการที่สูงขึ้น ให้ส่งออกไปยัง JMeter เมื่อคุณต้องการสร้างโหลดแบบกระจายที่เกินกว่าเครื่องเดียว Apidog สามารถส่งออก scenario ไปยัง JMeter ได้ เพื่อให้คุณยังคงใช้คำจำกัดความการทดสอบเดิมได้ในขณะที่ปรับขนาดแหล่งที่มาของโหลด

ดาวน์โหลด Apidog เพื่อดำเนินการทดสอบโหลดครั้งแรกกับ Endpoint ที่คุณมีอยู่แล้ว

การอ่านผลลัพธ์ประสิทธิภาพจริง

ตัวเลขที่ไม่มีการตีความเป็นเพียงเสียงรบกวน ลองดูตัวอย่างการทดสอบจริง: คุณทำการทดสอบโหลด GET /products โดยมีผู้ใช้เสมือนเพิ่มขึ้นจาก 0 เป็น 500 คนในระยะเวลาห้านาที

สำหรับผู้ใช้ 200 คนแรก เวลาตอบสนองเปอร์เซ็นไทล์ที่ 95 คงที่อยู่ที่ประมาณ 180 มิลลิวินาที และปริมาณงานเพิ่มขึ้นตามโหลด นี่คือโซนที่ปกติ; API ยังคงรองรับได้ ที่ประมาณ 280 ผู้ใช้ เวลาเปอร์เซ็นไทล์ที่ 95 เริ่มไต่ขึ้น 240 มิลลิวินาที จากนั้น 400 มิลลิวินาที จากนั้น 900 มิลลิวินาที ในขณะที่ปริมาณงานกลับนิ่งไม่เพิ่มขึ้น การนิ่งลงนั้นเป็นสัญญาณ: API ได้ชนขีดจำกัดแล้ว การเพิ่มผู้ใช้มากขึ้นในตอนนี้ทำให้เกิดการตอบสนองที่ช้าลง ไม่ใช่การทำงานที่สำเร็จมากขึ้น หลังจาก 420 ผู้ใช้ อัตราข้อผิดพลาดก็เริ่มสูงกว่า 1% เนื่องจากคำขอเริ่มหมดเวลา

บทสรุปที่ชัดเจนคือ API นี้สามารถรองรับผู้ใช้พร้อมกันได้ประมาณ 250 คนอย่างสบายๆ ภายในงบประมาณเวลา 200 มิลลิวินาที ขีดจำกัดที่ใช้งานได้จริงอยู่ที่ประมาณ 280 และเริ่มล้มเหลวที่ประมาณ 420 หากคุณคาดว่าจะมีปริมาณการใช้งานสูงสุด 200 ผู้ใช้พร้อมกัน คุณก็มีพื้นที่เหลือเฟือ หากคุณคาดว่าจะมี 350 คน คุณก็มีปัญหาที่ต้องแก้ไขก่อนเปิดตัว ไม่ใช่หลังจากเปิดตัว

นั่นคือสิ่งที่การทดสอบประสิทธิภาพให้: ไม่ใช่แค่ “ผ่าน” หรือ “ไม่ผ่าน” แต่เป็นแผนที่ที่ชัดเจนว่า API ทำงานได้ดีที่จุดใด มีความตึงเครียดที่จุดใด และพังทลายที่จุดใด

คอขวดประสิทธิภาพ API ที่พบบ่อย

เมื่อการทดสอบเผยให้เห็นขีดจำกัด สาเหตุส่วนใหญ่มักจะเป็นหนึ่งในไม่กี่สาเหตุที่พบบ่อย

การสืบค้นฐานข้อมูลที่ช้า เป็นสาเหตุที่พบบ่อยที่สุด คอลัมน์ที่ไม่ได้ทำดัชนี (unindexed column), รูปแบบการสืบค้นแบบ N+1 หรือการขาดขีดจำกัดการสืบค้น (query limit) ทำให้ Endpoint ที่เคยรวดเร็วช้าลงทันทีที่ปริมาณข้อมูลหรือการทำงานพร้อมกันเพิ่มขึ้น หากเวลาแฝงเพิ่มขึ้นในขณะที่ CPU ของเซิร์ฟเวอร์ยังคงต่ำ ให้สงสัยที่ฐานข้อมูลเป็นอันดับแรก

การเรียกใช้บริการภายนอกแบบบล็อก (Blocking external calls) ทำให้ Endpoint ช้าลงตามความเร็วของการพึ่งพาส่วนที่ช้าที่สุด API ที่เรียกผู้ให้บริการชำระเงินหรือบริการภายนอกแบบซิงโครนัสจะได้รับเวลาแฝงและการหยุดชะงักของบริการนั้นมาด้วย

Connection pool หมด (Connection pool exhaustion) ปรากฏภายใต้โหลดที่ต่อเนื่อง: API ขาดการเชื่อมต่อฐานข้อมูลหรือ HTTP client และคำขอจะเข้าคิวรอ นี่คือสิ่งที่มักพบในการทดสอบความทนทาน (soak test)

การแปลงข้อมูล (serialization) ที่ไม่มีประสิทธิภาพ สำหรับ payload การตอบสนองขนาดใหญ่จะใช้ CPU มาก การส่งคืนข้อมูลมากกว่าที่ไคลเอนต์ต้องการทำให้ทุกการตอบสนองใช้เวลาสร้างและถ่ายโอนช้าลง

การทดสอบประสิทธิภาพระบุว่าขีดจำกัดอยู่ที่ ไหน; การจับคู่กับเมตริกฝั่งเซิร์ฟเวอร์จะบอกคุณว่า ทำไม

การผนวกการทดสอบประสิทธิภาพเข้ากับกระบวนการของคุณ

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

กำหนดงบประมาณเวลาตอบสนองและอัตราข้อผิดพลาดสำหรับ Endpoint ที่สำคัญของคุณ และถือว่าการละเมิดนั้นเป็นความล้มเหลว เช่นเดียวกับการจัดการกับ assertion ที่เสีย ดำเนินการทดสอบโหลดแบบเบาเป็นส่วนหนึ่งของ CI/CD เพื่อให้ปัญหาประสิทธิภาพปรากฏขึ้นที่ pull request และสงวนการทดสอบความเค้น (stress) และความทนทาน (soak) แบบหนักไว้สำหรับการทดสอบก่อนการเผยแพร่ตามกำหนดการ

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

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

การทดสอบโหลด (Load testing) และการทดสอบความเค้น (Stress testing) แตกต่างกันอย่างไร? การทดสอบโหลดจำลองปริมาณการใช้งานที่คุณคาดหวังและยืนยันว่า API สามารถจัดการได้ การทดสอบความเค้นผลักดันเกินกว่านั้นเพื่อค้นหาจุดที่ระบบพังทลาย การทดสอบโหลดตรวจสอบการทำงานปกติ; การทดสอบความเค้นระบุโหมดความล้มเหลว

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

ฉันสามารถทดสอบประสิทธิภาพ API ก่อนที่ส่วนหลังบ้านจะเสร็จสมบูรณ์ได้หรือไม่? คุณสามารถทดสอบสัญญาและการออกแบบได้ แต่ตัวเลขเวลาแฝงที่มีความหมายต้องอาศัยโครงสร้างพื้นฐานจริง ใช้ mock server สำหรับการทำงานฟังก์ชันการทำงานในระยะแรก และดำเนินการทดสอบโหลดกับเวอร์ชันที่ใช้งานจริง

ควรดำเนินการทดสอบประสิทธิภาพบ่อยแค่ไหน? ดำเนินการทดสอบโหลดแบบเบาใน CI ทุกครั้งที่มีการเปลี่ยนแปลง Endpoint ที่สำคัญ และทำการทดสอบความเค้น (stress) และความทนทาน (soak) แบบเต็มรูปแบบก่อนการเผยแพร่หลักทุกครั้ง ประสิทธิภาพมักจะลดลงอย่างเงียบๆ ดังนั้นการตรวจสอบอย่างสม่ำเสมอจึงดีกว่าการทดสอบครั้งใหญ่เพียงครั้งเดียวก่อนเปิดตัว