Load-Testing ที่มากกว่าแค่อ่าน Output
Tags: testing
Published: 2022-12-27 07:43:27

โดยทั่วไปการทำ load-testing ส่วนใหญ่ให้ความสนใจไปกับ output ที่จะเกิดขึ้น และยกระดับความมั่นใจของระบบจาก output ที่ได้จากเครื่องมือ ในบทความนี้เป็นบันทึกที่อยากเล่าจากประสบการณ์ที่เคยได้ทำ และคิดว่ามีอะไรมากกว่า แค่ การอ่าน output ที่เกิดจากการทำ load-testing

โดยปกติ output ของการทำ load-testing จะมีค่าตามนี้

- Response time ความเร็วในการตอบสนอง
- Throughput ปริมาณข้อมูลที่รับได้
- Error rate จำนวนข้อผิดพลาดที่เกิดขึ้น
- Resource utilization ค่าการใช้งาน ต่าง ๆ ของ resource

แต่ในความจริงแล้ว การทำ load-testing สำหรับผมมันมีอะไรที่มากกว่าการมุ่งไปที่ output ที่ได้ และจำเป็นที่จะต้องได้ความร่วมมือจาก role ต่าง ๆ เพื่อเตรียมการ บันทึกผล และการตีความผลที่ได้ด้วย ไม่ว่าจะเป็น Infrastructure หรือ Developer เองก็ตาม 

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

**ก่อนทำ**

- Isolation and Symmetry Environment ต้องมั่นใจว่า environment ที่ใช้ทดสอบนั้น ไม่กระทบกับการใช้งานจริง และ เพียงพอต่อการเป็นตัวแทนในการใช้ในการประเมินได้

- Client Behavior บ่อยครั้งที่เครื่องมือ ในการทำ load-testing นั้นจะมีพื้นฐานการเรียกใช้งานที่ง่าย แต่มันไม่เหมือนพฤติกรรมที่จะเกิดขึ้นจริง โดยอาจจะต้องทำ script เพิ่มเติมเพื่อจำลองพฤติกรรม client ขึ้นมาเอง เช่น การจำลองการเล่น video streaming ของ client เป็นต้น
และ อย่าลืมที่จะ monitor เครื่องที่ run load-testing ด้วย

- Metrics and Log ค่าอะไรที่อยากเห็นระหว่างที่ทำ เพราะแต่ล่ะ role จะให้ความสนใจค่าที่ต่างกัน เช่น Infrastructure อาจจะสนใจ traffic usage ส่วน dev อาจจะสนใจ error rate หรือ response time, และ role อื่น ๆ ที่เกี่ยวข้อง เช่น DBA ก็อาจจะอยากเห็นค่าอื่น ๆ ที่ต่างออกไป ข้อมูลที่ได้ควรบันทึกเป็น time-series และมีการเก็บ log เพื่ออ่านและตีความผลต่อไปด้วย

- Data Input ข้อมูลที่จะใช้ในการทำ load-testing นั้นส่งผลต่อ process เป็น best, worst, average case หรือ random ในการทำ test


**ระหว่างทำ**

ในช่วงระหว่างที่ทำการ load-testing นั้น ขออนุญาติเปรียบเทียบว่าเหมือนเราทดสอบการเร่งเครื่องของรถยนต์นะครับ จากที่เคยทำมักจะมี 3 ช่วงที่เราควรสนใจและแต่ล่ะช่วงจะมีการใช้งาน resource และจุดที่สนใจที่ต่างกัน

- ช่วงเหยียบขันเร่ง (Ramp Up) ถ้าเปรียบเทียบช่วงนี้เหมือนทดสอบรถยนต์ว่ารถเราเร่งได้เท่าไหร่ เหยียบมิดทีเดียว หรือค่อย ๆ เหยียบ เพื่อเร่งความเร็ว ในส่วนนี้จะสะท้อนถึง Architecture ที่วางไว้ทำงานได้ดีหรือไม่ เช่น caching หรือ loadbalancer ที่เราใช้

- ช่วงค้างขันเร่ง (Stay) เมื่อการเทสผ่านช่วงเริ่มต้นไปได้แล้ว สิ่งนึงที่ควรดูด้วยคือ ระบบนั้นสามารถคงอยู่ต่อการใช้งานในระดับนี้ได้นานเท่าไหร่ มีการ leak ของ memory หรือ cpu รวมถึงลักษณะหรือ pattern การใช้งานแต่ล่ะ resource อย่างไร

- ช่วงถอนขันเร่ง (Ramp Down) ช่วงการหยุดใช้งานหรือออกจากการใช้งาน จำเป็นต้องดูว่า มีการคืน resource ที่ใช้งานหรือไม่ และใช้เวลานานหรือไม่ที่ resource ต่าง ๆ จะกลับคืนมาเป็นปกติ



**หลังทำ**

- การอ่านค่าหรือการตีความ จากผลลัพท์ที่ได้ ควรเกิดจากทุก ๆ ส่วนงาน ทั้งทีมที่ดูแล Infrastruture และ Developer เอง เพราะมุมมองต่อระบบของแต่ล่ะส่วนงานมักจะมองต่างกัน และบางจุดสามารถช่วยเหลือกันได้

- Resource Planing ของ Infrastructure ที่ใช้จะมีผลกระทบต่อผลการทดสอบหรือไม่ เช่นหากมี service อื่น เข้ามาใช้ resource เดียวกับเราจะเป็นอย่างไร

- load-testing เป็นสิ่งที่ควรทำ แต่ไม่ใช่ทุกสิ่ง ควรใส่ใจเรื่อง Scalability ของ service ไว้ด้วย

- Incident Response Plan เมื่อของจริง ไม่เป็นไปตามผลที่ทำไว้ ควรจะต้องทำอะไร

- Clear data ที่เกิดขึ้นระหว่างที่ทำ load-testing ด้วย

- ควรจะกลับมาทำซ้ำอีกเมื่อไหร่ เพื่อความมั่นใจว่าผลที่ได้ยังคงที่อยู่หรือไม่