perf
ทำการแปลบางส่วนจากบทความเรื่อง 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 กันอย่างไร ?