การทดสอบความสามารถในการปรับขนาดคืออะไร? เรียนรู้ด้วยตัวอย่าง
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
การทดสอบความสามารถในการปรับขนาด (Scalability Testing) วัดพฤติกรรมของแอปพลิเคชันเมื่อปริมาณผู้ใช้งาน ปริมาณข้อมูล หรืออัตราการทำธุรกรรมเพิ่มขึ้นหรือลดลง ซึ่งจะช่วยเปิดเผยจุดที่ประสิทธิภาพหยุดการปรับขนาด และระบุจุดคอขวดที่เป็นสาเหตุได้อย่างแม่นยำ
การทดสอบความสามารถในการปรับขนาดคืออะไร
การทดสอบความสามารถในการปรับขนาด การทดสอบความสามารถในการปรับขนาด (Scalability Testing) เป็นวิธีการทดสอบที่ไม่เกี่ยวข้องกับการทำงานโดยตรง ซึ่งใช้วัดประสิทธิภาพของระบบหรือเครือข่ายเมื่อจำนวนคำขอของผู้ใช้เพิ่มขึ้นหรือลดลง จุดประสงค์ของการทดสอบความสามารถในการปรับขนาดคือเพื่อให้แน่ใจว่าระบบสามารถรองรับการเพิ่มขึ้นของปริมาณการใช้งานของผู้ใช้ ปริมาณข้อมูล และความถี่ในการทำธุรกรรมตามที่คาดการณ์ไว้ เป็นการทดสอบความสามารถของระบบในการตอบสนองความต้องการที่เพิ่มขึ้น
การทดสอบความสามารถในการปรับขนาด (Scalability Testing) เป็นประเภทย่อยของการทดสอบประเภทหนึ่ง การทดสอบประสิทธิภาพดังนั้นจึงมุ่งเน้นไปที่พฤติกรรมของแอปพลิเคชันเมื่อถูกนำไปใช้งานบนระบบขนาดใหญ่หรือเมื่อใช้งานภายใต้ภาระงานที่มากเกินไป วิศวกรรมซอฟต์แวร์การทดสอบความสามารถในการขยายขนาด (Scalability Testing) จะวัดจุดที่แอปพลิเคชันหยุดการขยายขนาด และระบุสาเหตุที่อยู่เบื้องหลัง
เหตุใดจึงต้องทำการทดสอบความสามารถในการขยายขนาด?
ปัญหาด้านความจุแทบจะไม่ปรากฏให้เห็นระหว่างการทดสอบการทำงาน แต่จะปรากฏขึ้นในวันที่ซื้อขายคึกคักที่สุดของปี เมื่อมีการเปิดตัวแคมเปญการตลาด หรือเมื่อชุดข้อมูลที่เติบโตอย่างเงียบๆ มาสองปีในที่สุดก็ทำให้การค้นหาข้อมูลทุกครั้งช้าลง การทดสอบความสามารถในการขยายขนาดจะเปิดเผยข้อจำกัดเหล่านั้นในสภาพแวดล้อมที่มีการควบคุมก่อน โดยเฉพาะอย่างยิ่ง จะช่วยคุณในเรื่องต่อไปนี้:
- พิจารณาว่าแอปพลิเคชันสามารถรองรับปริมาณงานที่เพิ่มขึ้นได้อย่างไร และกราฟแสดงประสิทธิภาพเริ่มคงที่ที่จุดใด
- กำหนดจำนวนผู้ใช้งานพร้อมกันสูงสุดสำหรับเว็บแอปพลิเคชัน ก่อนที่เวลาตอบสนองจะกลายเป็นสิ่งที่ยอมรับไม่ได้
- ตรวจสอบความบกพร่องฝั่งไคลเอ็นต์และประสบการณ์ของผู้ใช้ปลายทางภายใต้ภาระงานหนัก เช่น การแสดงผลหน้าจอช้า
- ตรวจสอบความเสถียรและประสิทธิภาพการทำงานของเซิร์ฟเวอร์ รวมถึงการใช้งาน CPU สูงสุด การรั่วไหลของหน่วยความจำ และการหมดลงของกลุ่มการเชื่อมต่อ
ความสัมพันธ์นี้สามารถอธิบายได้ง่ายที่สุดด้วยภาพเส้นโค้ง: ปริมาณงานจะเพิ่มขึ้นตามปริมาณภาระงานที่เพิ่มขึ้น จนกระทั่งทรัพยากรนั้นเต็มพิกัด หลังจากนั้นผู้ใช้เพิ่มเติมจะทำให้คิวยาวขึ้นเท่านั้น
ประเภทของการทดสอบความสามารถในการขยายขนาด
ความสามารถในการปรับขนาดไม่ได้เป็นเพียงคุณสมบัติเดียว ดังนั้นแผนการทดสอบจึงมักครอบคลุมมากกว่าหนึ่งมิติ ประเภททั้งสี่ด้านล่างนี้เป็นประเภทที่ทีมส่วนใหญ่ใช้ในการวัด และสองประเภทแรกเป็นตัวกำหนดรูปแบบของสภาพแวดล้อมการทดสอบเอง
| ประเภท | อะไรคือมาตราส่วน | การทดสอบนี้พิสูจน์อะไร |
|---|---|---|
| ความสามารถในการปรับขนาดในแนวตั้ง (ขยายขนาด) | เพิ่ม CPU, หน่วยความจำ หรือพื้นที่จัดเก็บข้อมูลให้กับเซิร์ฟเวอร์เครื่องเดียว | เครื่องที่ได้รับการอัปเกรดหนึ่งเครื่องสามารถรองรับภาระเพิ่มเติมได้มากแค่ไหน และขีดจำกัดสูงสุดของเครื่องที่มีโหนดเดียวอยู่ที่เท่าใด |
| ความยืดหยุ่นในแนวนอน (ขยายขนาด) | เซิร์ฟเวอร์ คอนเทนเนอร์ หรือโหนดเพิ่มเติมที่อยู่เบื้องหลังโหลดบาลานเซอร์ | ไม่ว่าอัตราการรับส่งข้อมูลจะเพิ่มขึ้นตามสัดส่วนโดยประมาณของจำนวนโหนดที่เพิ่มเข้ามา หรือว่าทรัพยากรที่ใช้ร่วมกันจะเป็นตัวจำกัดอัตราการรับส่งข้อมูล |
| ความสามารถในการปรับขนาดเชิงฟังก์ชัน | ฟีเจอร์ โมดูล หรือบริการใหม่ | ฟังก์ชันการทำงานที่เพิ่มเข้ามานั้นสามารถใช้งานได้โดยไม่ทำให้ธุรกรรมที่มีอยู่เดิมเสียหายหรือไม่ |
| ความสามารถในการปรับขนาดด้านการบริหาร | ผู้ใช้ ผู้เช่า ทีม หรือสภาพแวดล้อมที่ต้องจัดการ | กระบวนการเริ่มต้นใช้งาน การอนุญาต และการตรวจสอบจะยังคงใช้ได้ผลหรือไม่เมื่อองค์กรเติบโตขึ้น |
การขยายขนาดในแนวตั้งนั้นง่ายกว่า เพราะสถาปัตยกรรมแทบจะไม่เปลี่ยนแปลง แต่เครื่องเดียวย่อมมีขีดจำกัดเสมอ การขยายขนาดในแนวนอนจะขจัดขีดจำกัดนั้นและเพิ่มความทนทานต่อความผิดพลาด แต่ต้องแลกมาด้วยความหน่วงของเครือข่าย ความสอดคล้องของข้อมูล และภาระงานด้านการประสานงาน ซึ่งทั้งหมดนี้การทดสอบจะต้องวัดผล ไม่ใช่การคาดเดา
สิ่งที่ต้องทดสอบในการทดสอบความสามารถในการขยายขนาด
ความสามารถในการขยายขนาดนั้นวัดได้จากผลการวัด ไม่ใช่แค่ความรู้สึก บันทึกคุณลักษณะต่อไปนี้ในทุกขั้นตอนการโหลด เพื่อให้เห็นแนวโน้ม ไม่ใช่แค่ตัวเลขสุดท้าย
| คุณลักษณะ | มันบอกคุณอะไร |
|---|---|
| เวลาตอบสนอง | ระยะเวลาระหว่างคำขอของผู้ใช้และการตอบกลับของระบบ ควรคงที่แม้ว่าการทำงานพร้อมกันจะเพิ่มขึ้นก็ตาม |
| การเปลี่ยนหน้าจอ | ความเร็วในการเปลี่ยนจากหน้าหนึ่งไปอีกหน้าหนึ่งเมื่อมีการใช้งานอย่างหนาแน่น |
| ทางเข้า | ปริมาณคำขอที่ประมวลผลต่อหน่วยเวลา; ระดับคงที่บ่งบอกถึงขีดจำกัดของความสามารถในการขยายขนาด |
| การวัดเวลา | เวลาใช้งานเซสชัน, เวลาบูตเครื่อง, เวลาพิมพ์, เวลาทำธุรกรรม และเวลาดำเนินการงาน |
| ประสิทธิภาพเมื่อเทียบกับจำนวนผู้ใช้ | การเปลี่ยนแปลงของแต่ละตัวชี้วัดเมื่อจำนวนผู้ใช้งานพร้อมกันเพิ่มขึ้นทีละน้อย |
| อัตราค่าบริการที่ร้องขอ | จำนวนคำขอต่อวินาที จำนวนธุรกรรมต่อวินาที และจำนวนการเข้าชมต่อวินาที |
| การใช้งานเครือข่าย | ปริมาณแบนด์วิดท์ที่ใช้และเวลาแฝงของแพ็กเก็ตระหว่างระดับต่างๆ |
| การใช้งาน CPU และหน่วยความจำ | ต้นทุนทรัพยากรต่อธุรกรรม ตัวเลขที่เพิ่มสูงขึ้นอย่างต่อเนื่องมักบ่งชี้ถึงการรั่วไหล |
| ตัวนับเซิร์ฟเวอร์เว็บ | จำนวนคำขอและการตอบสนองต่อวินาที ความลึกของคิว และการเชื่อมต่อที่ถูกปฏิเสธ |
| ประสิทธิภาพการทำงานภายใต้ภาระงาน | พฤติกรรมโดยรวมเมื่ออ่านค่าตัวชี้วัดทั้งหมดพร้อมกัน ณ จุดสูงสุด |
กลยุทธ์การทดสอบสำหรับการทดสอบความสามารถในการขยายขนาด
กลยุทธ์การทดสอบสำหรับการทดสอบความสามารถในการขยายขนาด (Scalability Testing) จะแตกต่างกันไปขึ้นอยู่กับประเภทของแอปพลิเคชันที่กำลังทดสอบ หากแอปพลิเคชันเข้าถึง... ฐานข้อมูลพารามิเตอร์ในการทดสอบจะรวมถึงขนาดของฐานข้อมูลที่สัมพันธ์กับจำนวนผู้ใช้ และอื่นๆ
ข้อกำหนดเบื้องต้นสำหรับการทดสอบความสามารถในการปรับขนาด
- ความสามารถในการกระจายโหลด — ตรวจสอบว่าเครื่องมือทดสอบโหลดรองรับการสร้างโหลดจากเครื่องจักรหลายเครื่องและควบคุมจากจุดศูนย์กลางหรือไม่
- Operaระบบ ting — ตรวจสอบดูสิ ระบบปฏิบัติการ ตัวแทนสร้างโหลดและตัวควบคุมหลักทดสอบโหลดทำงานภายใต้...
- หน่วยประมวลผล — ตรวจสอบว่าตัวแทนผู้ใช้เสมือนและตัวควบคุมหลักสำหรับการทดสอบโหลดต้องการ CPU ประเภทใด
- หน่วยความจำ — ตรวจสอบว่าหน่วยความจำขนาดเท่าใดจึงจะเพียงพอสำหรับเอเจนต์ผู้ใช้เสมือนและโหลดมาสเตอร์สำหรับการทดสอบ
- สภาพแวดล้อมการทดสอบ — ตรวจสอบว่า สภาพแวดล้อมการทดสอบ สะท้อนกระบวนการผลิตได้อย่างใกล้ชิดจนสามารถนำผลลัพธ์ไปปรับใช้ได้
วิธีการทดสอบ Scalability
- กำหนดกระบวนการที่ทำซ้ำได้สำหรับการดำเนินการทดสอบความสามารถในการขยายขนาดตลอดวงจรชีวิตของแอปพลิเคชัน
- กำหนดเกณฑ์สำหรับการขยายขนาด
- คัดเลือกเครื่องมือซอฟต์แวร์ที่จำเป็นสำหรับรันการทดสอบโหลด
- ตั้งค่าสภาพแวดล้อมการทดสอบและกำหนดค่าฮาร์ดแวร์ที่จำเป็นสำหรับการดำเนินการทดสอบความสามารถในการปรับขนาด
- วางแผนสถานการณ์การทดสอบรวมถึงการทดสอบความสามารถในการขยายขนาด
- สร้างและตรวจสอบสคริปต์ผู้ใช้เสมือน
- สร้างและตรวจสอบสถานการณ์การทดสอบโหลด
- ดำเนินการทดสอบ
- ประเมินผล
- จัดทำรายงานที่จำเป็น
แผนทดสอบความสามารถในการปรับขนาด
ก่อนที่จะเริ่มสร้างชุดทดสอบจริง ๆ ให้วางแผนการทดสอบอย่างละเอียดเสียก่อน นี่เป็นขั้นตอนสำคัญที่จะช่วยให้มั่นใจได้ว่าชุดทดสอบนั้นสอดคล้องกับข้อกำหนดของแอปพลิเคชัน
ต่อไปนี้เป็นคุณลักษณะสำหรับการสร้างสิ่งที่มีการกำหนดไว้อย่างชัดเจน แผนการทดสอบ สำหรับการทดสอบความสามารถในการปรับขนาด
- ขั้นตอนสำหรับสคริปต์สคริปต์ทดสอบควรมีขั้นตอนโดยละเอียดที่ระบุการกระทำที่ผู้ใช้จะดำเนินการอย่างแม่นยำ
- ข้อมูลรันไทม์แผนการทดสอบควรระบุข้อมูลระหว่างการทำงานที่จำเป็นสำหรับการโต้ตอบกับแอปพลิเคชัน
- การทดสอบที่ขับเคลื่อนด้วยข้อมูลหากสคริปต์ต้องการข้อมูลที่เปลี่ยนแปลงไปในระหว่างการทำงาน คุณจำเป็นต้องเข้าใจฟิลด์ทั้งหมดที่ต้องการข้อมูลเหล่านั้น
ตัวอย่างการทดสอบความสามารถในการขยายขนาด
ลองพิจารณาร้านค้าออนไลน์แห่งหนึ่งที่คาดว่าจะมีลูกค้าพร้อมกัน 2,000 รายในช่วงเทศกาลลดราคา ทีมงานตกลงกันในเกณฑ์การผ่านก่อนว่า การทำธุรกรรมชำระเงินต้องเสร็จสมบูรณ์ภายในเวลาไม่ถึงสามวินาทีสำหรับผู้ใช้ 95 เปอร์เซ็นต์ โดยมีอัตราข้อผิดพลาดต่ำกว่าหนึ่งเปอร์เซ็นต์
จากนั้น การทดสอบจะรันสคริปต์ browse-search-cart-checkout เดียวกันที่จำนวนผู้ใช้เสมือน 250, 500, 1,000, 1,500 และ 2,000 คน เวลาตอบสนองคงที่อยู่ที่ประมาณสองวินาทีจนถึง 1,000 คน เพิ่มขึ้นเป็น 2.8 วินาทีที่ 1,500 คน และถึงเก้าวินาทีที่ 2,000 คน ในขณะที่ CPU ของฐานข้อมูลทำงานที่ 98 เปอร์เซ็นต์ ดังนั้น ขีดจำกัดด้านความสามารถในการขยายขนาดจึงอยู่ที่ประมาณ 1,500 คน และคอขวดอยู่ที่ส่วนของฐานข้อมูล ไม่ใช่เซิร์ฟเวอร์แอปพลิเคชันที่ทีมวางแผนจะเพิ่มเข้ามา
เครื่องมือทดสอบความสามารถในการขยายขนาด
การทดสอบความสามารถในการขยายขนาด (Scalability Testing) จำเป็นต้องใช้เครื่องมือที่สามารถสร้างภาระงานจากเครื่องหลายเครื่องพร้อมกันและรายงานผลลัพธ์ไปยังส่วนกลางได้ โดยปกติแล้วการเลือกเครื่องมือจะขึ้นอยู่กับภาษาหลักที่ทีมใช้และโปรโตคอลที่กำลังทดสอบ
| เครื่องมือ | การเขียนสคริปต์ | เหมาะที่สุดสำหรับ |
|---|---|---|
| Apache JMeter | แผนการทดสอบ GUI บวก XML Java ตาม | รองรับโปรโตคอลหลากหลายประเภท รวมถึง JDBC, JMS, LDAP และ SOAP |
| กราฟาน่า เค6 | Javaสคริปต์หรือ TypeScript | การทดสอบ API และไมโครเซอร์วิสที่เชื่อมโยงเข้ากับไปป์ไลน์ CI/CD |
| Gatling | JavaDSL ของ Kotlin หรือ Scala | จำนวนผู้ใช้งานเสมือนสูงต่อตัวจ่ายสารฉีด พร้อมรายงาน HTML ที่ละเอียดครบถ้วน |
| ปาทังกา | ที่ราบ Python | Python ทีมที่ต้องการขยายขีดความสามารถของไคลเอ็นต์ให้เหนือกว่า HTTP |
| โหลดรันเนอร์ | สคริปต์ที่คล้ายกับภาษา C ที่บันทึกไว้ใน VuGen | ระบบคอมพิวเตอร์ขนาดใหญ่ที่มีแอปพลิเคชันแบบดั้งเดิมและแอปพลิเคชันสำเร็จรูป |
ตัวรันที่โฮสต์บนคลาวด์ เช่น BlazeMeterLoadView และ Gatling Enterprise เป็นโปรแกรมที่ใช้บนกลไกเหล่านี้หลายตัว และควรพิจารณาใช้เมื่อการทดสอบต้องการผู้ใช้เสมือนจริงหลายหมื่นคน หรือปริมาณการใช้งานจากหลายภูมิภาคทางภูมิศาสตร์ สามารถดูรายละเอียดเพิ่มเติมเกี่ยวกับหมวดหมู่นี้ได้ในคู่มือ เครื่องมือทดสอบประสิทธิภาพ.
ความท้าทายและแนวปฏิบัติที่ดีที่สุดในการทดสอบความสามารถในการขยายขนาด
ผลลัพธ์ด้านความสามารถในการขยายขนาดที่น่าผิดหวังที่สุด tracกลับไปที่การตั้งค่าการทดสอบแทนที่จะเป็นแอปพลิเคชัน นี่คือปัญหาที่เกิดขึ้นซ้ำ ๆ และนี่คือพฤติกรรมที่ขัดขวางการแก้ไขปัญหาเหล่านั้น
ความท้าทายทั่วไป
- สภาพแวดล้อมที่มีขนาดเล็กเกินไป — ชุดทดสอบที่มีหน่วยความจำครึ่งหนึ่งของหน่วยความจำใช้งานจริง รายงานว่าพบปัญหาคอขวด ซึ่งปัญหานี้ไม่มีอยู่ในการใช้งานจริง
- แบบจำลองภาระงานที่ไม่สมจริง — สคริปต์ที่ไม่มีช่วงเวลาประมวลผลหรือการเปลี่ยนแปลงข้อมูล จะไปเรียกใช้แคชที่ผู้ใช้จริงอาจมองข้ามไป
- ผลลัพธ์ที่ดังมาก — การปรับขนาดอัตโนมัติ การจัดการขยะ และฮาร์ดแวร์คลาวด์ที่ใช้ร่วมกัน ทำให้การทำงานสองครั้งที่เหมือนกันทุกประการให้ผลลัพธ์ที่แตกต่างกัน
- การสังเกตการณ์ที่บางเบา — หากไม่มีข้อมูลตัวชี้วัดฝั่งเซิร์ฟเวอร์ ผลลัพธ์ที่ช้าจะแสดงให้เห็นว่ามีบางอย่างผิดพลาด แต่ไม่ได้ระบุว่าอะไรผิดพลาด
- ราคา — การสร้างปริมาณการใช้งานพร้อมกันในระดับสูงมาก จำเป็นต้องใช้เครื่องสร้างโหลดจำนวนมาก ซึ่งอาจทำให้งบประมาณที่ใช้ต่ำกว่าที่กำหนดได้ง่าย
ปฏิบัติที่ดีที่สุด
- ตกลงเกณฑ์การผ่าน เช่น เปอร์เซ็นไทล์ของเวลาตอบสนองและอัตราข้อผิดพลาดสูงสุด ก่อนเริ่มการทดลองครั้งแรก
- เพิ่มภาระทีละขั้นตอนตามแผน และคงภาระในแต่ละขั้นตอนไว้ให้นานพอจนกว่าระบบจะเสถียร
- ควรปรับเปลี่ยนข้อมูลทดสอบสำหรับผู้ใช้เสมือนแต่ละราย เพื่อไม่ให้การแคชข้อมูลทำให้ผลลัพธ์ดูดีเกินจริง
- รวบรวมข้อมูลตัวชี้วัดแอปพลิเคชัน ฐานข้อมูล และโครงสร้างพื้นฐาน ควบคู่ไปกับตัวเลขฝั่งไคลเอ็นต์
- จัดเก็บสคริปต์ทดสอบไว้ในระบบควบคุมเวอร์ชัน และทำการตรวจสอบความสามารถในการปรับขนาดแบบสั้น ๆ ในทุก ๆ การสร้าง จากนั้นทำการทดสอบแบบเต็มรูปแบบก่อนที่จะปล่อยเวอร์ชันใช้งานจริง
- ควรเปรียบเทียบแนวโน้มจากโครงการต่างๆ แทนที่จะพิจารณารายงานเพียงฉบับเดียว
การทดสอบความสามารถในการขยายขนาดเทียบกับการทดสอบการรับโหลด
สองอย่างนี้มักถูกเข้าใจผิดเพราะทั้งคู่ต่างก็ใช้โหลด ความแตกต่างอยู่ที่คำถามที่แต่ละอย่างตอบ: การทดสอบความสามารถในการขยายขนาด (Scalability Testing) ถามว่าระบบสามารถเติบโตได้ไกลแค่ไหน ในขณะที่... โหลดการทดสอบ ถามว่าสามารถรับมือกับภาระที่คาดการณ์ไว้ได้หรือไม่
| ฐาน | การทดสอบความสามารถในการปรับขนาด | โหลดการทดสอบ |
|---|---|---|
| โฟกัส | โดยจะเน้นที่ประสิทธิภาพของเว็บไซต์ ซอฟต์แวร์ ฮาร์ดแวร์ และแอปพลิเคชันของคุณ เมื่อมีการเปลี่ยนแปลงขนาดหรือปริมาณของระบบเพื่อตอบสนองความต้องการที่เพิ่มขึ้น | การทดสอบโหลดมุ่งเน้นการทดสอบแอปพลิเคชันภายใต้ภาระงานหนัก เพื่อตรวจสอบว่าจุดใดที่ระบบเริ่มตอบสนองผิดพลาด |
| รูปแบบการโหลด | ภาระงานจะเพิ่มขึ้นทีละขั้นตอน และอาจมีการเพิ่มทรัพยากรระหว่างขั้นตอนต่างๆ | โหลดจะถูกคงไว้ที่ระดับสูงสุดที่คาดการณ์ไว้เป็นระยะเวลาคงที่ |
| คำถามได้รับคำตอบแล้ว | ระบบนี้สามารถขยายไปได้ไกลแค่ไหน และมีข้อจำกัดอะไรบ้าง? | ระบบนี้บรรลุเป้าหมายที่ตกลงกันไว้ในวันนี้หรือไม่? |
| ผลลัพธ์ทั่วไป | ข้อจำกัดด้านความสามารถในการขยายขนาด ปัญหาคอขวด และแผนการจัดการกำลังการผลิต | ผ่านหรือไม่ผ่านเกณฑ์เป้าหมายด้านเวลาตอบสนองและปริมาณงาน |
ทั้งคู่นั่งอยู่ใต้ การทดสอบที่ไม่เกี่ยวข้องกับการทำงาน ร่มข้างๆ ทดสอบความเครียด, การทดสอบหนามแหลม, การทดสอบความอดทน และ การทดสอบปริมาตรและกลยุทธ์การวัดผลที่มีประสิทธิภาพมักจะใช้การทดสอบหลายๆ ครั้งกับสคริปต์เดียวกัน
