แปลเรื่อง Performance Testing

ทำการแปลบางส่วนจากบทความเรื่อง Performance Testing in a Nutshell ซึ่งทำการอธิบายเรื่องของ Performance Testing ได้อย่างน่าสนใจ ทั้งแนวคิด และ แนวทางในการทดสอบ ทั้งการเตรียม environment ต่าง ๆ ทั้งการเขียน script เพื่อทดสอบ ทั้งการวิเคราะห์ผลการทดสอบ ทั้งการ monitoring ระบบ และ Lesson learn ต่าง ๆ ดังนั้น เรามาเริ่มเดินทางไปยัง Performance Testing กันเลย

เรื่องของ Performance testing เป็นสิ่งที่มักหลงลืมกันได้ง่าย

แต่มักจะมีความสำคัญเมื่อถึงเวลาส่งมอบระบบงาน (Deadline) เนื่องจาก เรามักทดสอบในช่วงท้ายของการพัฒนาระบบงาน ทำเหมือนกับว่า การทดสอบมันไม่จำเป็น หรือ เป็นชนชั้นที่สอง !! คำถามคือ ถ้าทดสอบแล้วไม่ผ่านจะต้องทำอย่างไร ? 1. ต้องแก้ไขให้ทดสอบผ่านให้ได้ บ่อยครั้งต้องรื้อ !! 2. ขยายเครื่องได้ไหม ? บ่อยครั้งมันคือการหนีปัญหา 3. ปล่อยมันไปก่อน พยายามพูดต่าง ๆ นานา เพื่อให้ลูกค้ายอมรับ 4. ??? ดังนั้น ความท้าทายหนึ่งที่ เราจะต้องทำก็คือ การทำ Performance testing ตั้งแต่เริ่มการพัฒนาระบบงาน แต่ว่าจะทำอย่างไรดีล่ะ ?

ก่อนจะเริ่มทำการทดสอบ ควรต้องทำความเข้าใจระบบ

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

คำเตือน อย่าปล่อยให้การพูดคุยเรื่อง Performance test ไปอยู่ช่วงกลาง หรือ ช่วงท้ายของการพัฒนา มิเช่นนั้น ค่าใช้จ่ายมันจะเพิ่มแบบทวีคูณ

ในการพัฒนาระบบงานนั้น

เรื่องการทดสอบ Performance ควรจะต้องเกิดขึ้นอยู่อย่างเสมอ และเป็นสิ่งที่ต้องการการทำงานเป็นทีม ทั้ง developer, tester, operation และคนที่เกี่ยวข้อง เพื่อทำการทดสอบ ดูแลรักษาระบบ และให้ผลการทดสอบมันใกล้กับสิ่งที่คาดหวังไว้ เนื่องจากการทดสอบมันต้องการคนที่มีความรู้มากมาย ไว้ว่าจะเป็นเรื่อง การเขียน test script ไม่ว่าจะเป็นเรื่อง การใช้เครื่องมือ ไม่ว่าจะเป็นเรื่อง การวิเคราะห์ผล ไม่ว่าจะเป็นเรื่อง การ monitoring ระบบ ไม่ว่าจะเป็นเรื่อง แผนการทดสอบ ไม่ว่าจะเป็นเรื่อง การทดสอบซ้ำ ซึ่งต้อง reset ระบบกลับไปยังจุดเริ่มต้นเหมือนกัน ไม่ว่าจะเป็น .... มันเยอะมาก ๆ ดังนั้นมาดูกันว่า เราจะต้องเตรียมอะไรกันบ้าง ?

1. เรื่องของ Environment

ถ้าเป็นแต่ก่อนเราจะใช้เครื่องภายในองค์กร แต่มันก็มีข้อจำกัดหลาย ๆ อย่าง ซึ่งปัจจุบันมีเรื่องของ Cloud เข้ามาช่วย ทำให้การทดสอบมันง่ายและสะดวกมากยิ่งขึ้น ที่สำคัญ การดูแลรักษาก็ง่ายกว่าเดิมอีก แต่ถ้าองค์กรไหนที่มีข้อจำกัดมากมาย เช่นการเข้าถึง server ต่าง ๆ จากภายนอกต้องผ่าน VPN, Firewall หรือบางที่ก็ไม่สามารถเข้าถึงได้เลย มีทางเดียวก็คือ ต้องซื้อเครื่องที่ใหญ่กว่าเดิม หรือ จำนวนเครื่องมากขึ้น เพื่อทำให้การทดสอบมันมากขึ้นนั่นเอง

มาถึงเรื่องของ configuration ต้องคล้ายหรือเหมือน production ให้มากที่สุด เพื่อลดความผิดพลาดต่าง ๆ จากการทดสอบ

2. เรื่องของ test script

ประกอบไปด้วย การจัดการเรื่อง session การจัดการเรื่อง caching และที่สำคัญมากคือ ควรทำการทดสอบในหลาย ๆ layer ตาม Pyramid testing ตัวอย่างเช่น การทดสอบระดับ functional การทดสอบในระดับ service การทดสอบในระดับ integration ระหว่าง service การทดสอบในระดับ system

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

3. เรื่องของระบบ Monitoring ระบบ

ในการทดสอบ performance ของระบบนั้น ระบบ monitoring มันมีความสำคัญอย่างมาก ขาดไม่ได้เลย คำถามแรก คือ ทำอย่างไรล่ะ ? การติดตั้งเครื่องมือสำหรับระบบ monitoring นั้น ควรให้อยู่ใกล้กับ application server ให้มากที่สุด เพื่อหลีกเลี่ยงปัญหาทางด้าน network เพื่อหลีกเลี่ยงปัญหาการสูญหายของข้อมูล แต่ไม่ควรติดตั้งไว้เครื่องเดียวกับระบบที่ถูกทดสอบโดยเด็ดขาด มิเช่นนั้น มันจะส่งผลกระทบต่อผลการทำงานของระบบ !! คำถามต่อมา เราจะวัดค่าอะไรจากระบบ Monitoring บ้างล่ะ ? แบ่งออกเป็นสองส่วนคือ 1. Application level สิ่งที่ต้องดูเลยก็คือ

• Response time คือเวลาการทำงานของแต่ละ request ตั้งแต่เริ่มต้นจนสิ้นสุด
• Throughput คือจำนวน request ที่ระบบทำงานได้ในเวลาหนึ่ง ๆ เช่น จำนวน request ใน 1 วินาทีเป็นต้น

2. Infrastructure level สิ่งที่ต้องดูเลยก็คือ การใช้งาน CPU และ Memory ของแต่ละเครื่อง และ service ซึ่งมีเครื่องมือในการแสดงผล และ วิเคราะห์ เช่น Graphite, Jemalloc และ JProfile เป็นต้น เมื่อทำการทดสอบเสร็จสิ้นในแต่ละครั้งควรทำการบันทึกผลไว้เสมอ มันจะทำให้เราเห็นว่า การทำงานของระบบมีแนวโน้มอย่างไร จากนั้นทำการวิเคราะห์เจาะเกมส์ เพื่อทำให้เรารู้ว่าต้องปรับปรุงและแก้ไขอย่างไร ว่าระบบส่วนไหนเกิดปัญหาคอขวดบ้าง ทั้งวิธีการทดสอบ และ ระบบงาน

4. เรื่องของเครื่องมือ

การเลือกเครื่องมือสำหรับการทดสอบ performace มันเป็นอีกเรื่องที่สำคัญ โดยมีคำแนะนำสำหรับการเลือกดังนี้

• ง่ายต่อการสร้าง และ ดูแล user agent หรือไม่ ?
• ง่ายต่อการสร้าง และ ดูแลการทดสอบหรือไม่ ?
• มี log ไว้สำหรับการ debug และ ตรวจสอบผลการทดสอบหรือไม่ ?
• สร้างจำนวน user session เยอะ ๆ หรือไม่ ?
• สามารถจัดการเรื่องของ Ramp up/Ramp down ได้หรือไม่ ?
• สามารถทดสอบแบบ Data-Driven ได้หรือไม่ ?
• สามารถทำงานร่วมกับระบบ Web และ API ได้หรือไม่ ?
• สามารถทำงานหลาย OS ได้หรือไม่ ?
• สามารถจัดเก็บประวัติการทดสอบได้หรือไม่ ?
• สามารถแสดงผลการทดสอบในรูปแบบต่าง ๆ ได้หรือไม่ ?
• สามารถทำงานแบบอัตโนมัติร่วมกับระบบ Continuous Integration ได้หรือไม่ ?
• สามารถทำงานบน mobile ได้หรือไม่ ?
• สามารถทดสอบบน browser ชนิดต่าง ๆ ได้หรือไม่ ?
• สามารถจำลองความเร็วของ network ได้หรือไม่ ? เช่น 2G, 3G เป็นต้น

ปิดท้ายด้วย Lesson learn ที่น่าสนใจ

1. หลีกเลี่ยงการทำงานแบบ backgroud process เนื่องจากเป้าหมายหลักของการทดสอบ เพื่อรองรับและให้บริการแก่ผู้ใช้งาน หรือ ลูกค้า ดังนั้น ถ้าแต่ละ request จากผู้ใช้งานมายังระบบงาน แล้วระบบไปทำงานเหล่านั้นแบบ background process มันคือการซ่อนปัญหาไว้ ข้อดีของการทำแบบนี้คือ ระบบทำงานได้อย่างรวดเร็ว ข้อเสียของการทำแบบนี้คือ เพิ่มความซับซ้อนของระบบขึ้นอย่างมาก การแก้ไข คือ ควรเพิ่มจำนวนเครื่องขึ้นมา เพื่อรองรับผู้ใช้งานดีกว่านะ 2. การทดสอบแต่ละครั้ง ควรเปลี่ยนค่าต่าง ๆ เพียงหนึ่งค่าเท่านั้น (One Parameter Principle ) ในการทดสอบนั้น เรามักจะทำการแก้ไขค่า configuration ต่าง ๆ แต่ขอแนะนำให้เปลี่ยนครั้งละ 1 ค่าเท่านั้น เพื่อทำให้เราเห็นว่า ค่าใดมันส่งผลดีผลเสียต่อระบบบ้าง ดังนั้น ให้ทำการทดสอบแบบ small step แบบนี้ไปเรื่อย ๆ ทำการวิเคราะห์ และ แก้ไขต่อไป 3. ให้คิดถึงพฤติกรรมการใช้งานจริง ๆ ของผู้ใช้งานเป็นหลัก Flow ของการทดสอบนั้น ควรเป็นสิ่งที่ผู้ใช้งานส่วนใหญ่ใช้จริง ๆ มิใช่การมโนขึ้นมาเอง ถ้าเป็นระบบงานเดิม หรือ Legacy system ก็ให้เอาข้อมูลจาก production server มาวิเคราะห์ซะ 4. ว่าด้วยเรื่องของการทำ Caching ในบางครั้งการทำ caching ขึ้นมาก็ช่วยทำให้ประสิทธิภาพของระบบดีขึ้น แต่ในบางครั้งก็ไม่ได้ส่งผลดีอะไรขึ้นมา ดังนั้น ตรงนี้ควรทำความเข้าใจเกี่ยวกับ caching ให้ดี แถม caching มันมีหลาย layer อีกด้วย

• ไม่ว่าจะเป็นระดับ network
• ไม่ว่าจะเป็นระดับ application
• ไม่ว่าจะเป็นระดับ service
• ไม่ว่าจะเป็นระดับ database

5. ระมัดระวังการ query ที่ใช้เวลา และ resource เยอะ ๆ ถ้า query สำหรับการดึงข้อมูลจาก database มันแย่ มันช้า หรือ ใช้ resource มากมาย จะส่งผลให้การทำงานของระบบช้าลงไปอย่างมาก ดังนั้นสิ่งที่ต้องมีก็คือ ระบบ monitoring สำหรับการทำงานของการ query หรือ Slow log เพื่อทำให้เรารู้ว่า มีจุดใจที่ต้องแก้ไขบ้าง 6. ลดจำนวนการเรียกใช้งานระหว่างระบบ มักพบว่าระหว่างฝั่ง frontend และ backend นั้น ในแต่ละ feature มักจะมีการเรียกใช้งาน backend จาก frontend จำนวนมาก บางครั้งมากจนเกินไป หรือ ถี่จนเกินไป ดังนั้น แนะนำให้ลดจำนวนการเรียกใช้งานลงซะ

วันนี้คุณทำ Performance testing กันหรือยัง ? วันนี้คุณทำ Performance testing กันอย่างไร ?