เมื่อว่าด้วยเรื่อง Performance เรามักจะได้ยินคำว่า
ระบบของเรามันทำงานช้านะ พวกคุณทำให้มันทำงานเร็วกว่านี้ได้ไหม !!!
แล้วเราทำอะไรได้บ้างล่ะ ?
ก็ต้อง tunning performance ใช่ไหมล่ะ ?
แต่ปัญหาก็คือ คุณจะใช้ตัวชี้วัดอะไร ?
เพื่อมากำหนดความหมายของคำว่า เร็ว
สิ่งหนึ่งที่คุณควรคิดไว้เสมอ คือ มันไม่มีหรอกคำว่าเร็วที่สุด
แต่มันมีแต่คำว่า เร็วกว่าเดิม อยู่อย่างเสมอและต่อเนื่อง
ดังนั้น เรามากำหนด performance requirement กันหน่อยดีไหม ?
ก่อนอื่นๆ มาดู performance requirement ที่มันแย่ๆ
ทางฝ่าย business มักจะคิดเรื่องของ functional requirement ได้อย่างดี
แต่เมื่อต้องคิดเรื่องอื่นๆ ที่อยู่นอกเหนือ functional requirement เช่น
- Usability
- Compatibility
- Performance
มักจะคิดไม่ออกว่ามันต้องมีอะไรบ้าง และ เป็นอย่างไร
บางครั้งจะเขียนว่า ต้องทำให้มั่นใจว่ามันจะเร็วที่สุด !!
ซึ่งมันน่ากลัวมากๆ แต่อาจจะดีขึ้นมาหน่อย ถ้าเขียนประมาณว่า
- 95% ของการทำงานในระบบ จะต้องส่งผลลัพธ์กลับมาภายใน 5 วินาที
- ระบบต้องรองรับจำนวนผู้ใช้งานพร้อมๆ กันได้ 100 คน
จากทั้งสองข้อนั้น มันก็ไม่ได้แย่อะไรนะ
แต่สิ่งที่ต้องทำให้ชัดก็คือ รายละเอียดของแต่ละข้อนั่นเอง
95% ของการทำงานในระบบ จะต้องส่งผลลัพธ์กลับมาภายใน 5 วินาที
สิ่งที่อาจจะต้องสอบถามต่อไปก็คือ
แล้วอีก 5% ที่เหลือล่ะ จะต้องส่งผลลัพธ์กลับมาภายในเวลาเท่าไร เช่น 10 วินาทีหรือเปล่า ?
ถ้าทำงานเกิน 10 วินาที จะต้อง timeout และตัดการทำงานนั้นทิ้งไปเลยไหม ?
ซึ่งอย่าไปสนใจเพียงแค่เป้าหมายเดียวเท่านั้น ต้องดูเป้าหมายอื่นๆ ด้วย
เมื่อกลับมาที่เป้าหมายหลัก
จะต้องถามรายละเอียดอีกว่า แต่ละ operation ในระบบงาน
ต้องทำงานภายใต้เงื่อนไขเดียวกันไหม
หรืออาจจะต้องแยกแต่ละ operation ออกมาอีก เช่น
- การค้นหาข้อมูลต้องได้ผลลัพธ์กลับมาภายใน 5 วินาที ?
- การชำระเงินผ่าน payment ของธนาคาร ต้องทำงานเสร็จภายใน 5 วินาที ?
สิ่งเหล่านี้เพื่อต้องการทำให้เห็นว่า
ในแต่ละ operation มันไม่น่าจะมีเวลาในการทำงานเท่าๆ กันหรอกนะ
แต่ควรแยกแต่ละ operation ออกมาเป็นกลุ่ม
ตามเวลาการทำงานที่คาดว่าจะทำงานได้จริงๆ
ซึ่งจะช่วยให้การวัดผลง่ายขึ้น และ สมเหตสมผลมากขึ้นกว่าเดิม
โดยเรื่องนี้เรามักจะเรียกว่า “Acceptance latency distribution per operation”
ระบบต้องรองรับจำนวนผู้ใช้งานพร้อมๆ กันได้ 100 คน
- สิ่งที่มันน่าสนใจคือ ผู้ใช้งาน 100 คนเข้ามาทำอะไรพร้อมๆ กัน ?
- เปิด website หน้าแรก ซึ่งมีข้อมูลที่ดึงมาแสดงผลมากกว่า 500 ครั้ง ?
- ทำการกด link รูปภาพ ?
- ทำการเปิด vdo ขนาด 10 MB ?
ลองคิดดูว่า ถ้าเป็นอย่างแรกและหลังมันจะน่ากลัวไหม ?
ดังนั้น เราควรคุยในรายละเอียดเพื่อทำให้เข้าใจ requirement จริงๆนะ
เช่น มันอาจจะหมายถึง 100 คน อาจจะหมายถึง 100 operation ที่เกิดขึ้นจริงในระบบ
ถ้าแต่ละ operation ใช้เวลาทำงาน 10 วินาที
หมายความว่าระบบจะสามารถรองรับได้ 10 operation ต่อวินาทีนะ
ซึ่งค่านี้เรียกว่า ค่า Throughput
แต่ถ้าอยากเพิ่มการทำงานให้สูงขึ้น คุณต้องลดเวลาการทำงานของแต่ละ operation ลงไป
ดังนั้น แทนที่จะใช้คำว่า ผู้ใช้งานทำงานพร้อมๆ กัน หรือ concurrent user
ก็ให้ใช้คำ หรือ คำอธิบายที่เข้าใจได้ง่าย
หรือสื่อสารถึงพฤติกรรมเฉพาะไปเลย จะชัดเจนกว่าเยอะครับ
เช่น ระบบต้องสามารถรับการสร้าง order จำนวน 1000 order ใน 1 วินาที เป็นต้น
ซึ่งมันสามารถใช้ชี้วัดได้ชัดเจนมากกว่าไหม ?
สิ่งที่ยังขาดไปก็คือ เรื่อง Capacity planning สินะ
- จำนวนข้อมูลที่คุณคาดหวังไว้ใน performance requriement คืออะไร ?
- สิ่งที่คุณคาดไว้ไว้คือ มีจำนวนผู้ใช้งาน 10,000 คน และ จำนวน transaction 1 ล้าน transaction ?
- ระบบจะต้องสามารถเก็บข้อมูล ผู้ใช้งาน 1 ล้านคน และ จำนวน transaction 1 พันล้าน transaction ?
ชัดเจนไหม สำหรับจำนวนข้อมูลที่ระบบต้องสามารถรองรับ และ จัดเก็บได้ ?
เมื่อ performance requirement ชัดเจนแล้ว
คุณสามารถทำการกำหนด infrastructure ต่างๆ เพื่อรองรับการขยายตัวของระบบ
แต่สิ่งที่หนึ่งที่ต้องรู้ก็คือ พฤติกรรมที่เกิดขึ้นในระบบหลังจากการ deploy ไปแล้ว
นั่นคือ ระบบ monitoring
เพื่อให้คุณรู้ว่า เมื่อใดควรจะเพิ่มหรือลดสิ่งต่างๆ ในระบบ เช่น
- Bandwidth ของ network
- Storage
- Memory
โดยสรุปแล้ว
เท่าที่อธิบายมา เป็นเพียงแค่ส่วนหนึ่งของ performance requirement เท่านั้น
เพื่อทำให้เห็นว่า เราควรกำหนดเรื่องเหล่านี้ขึ้นมาตั้งแต่แรกด้วยเช่นกัน
เพื่อทำให้มันชัดเจน และ เข้าใจตรงกัน
ไม่ใช่หน้าที่ของใครคนใดคนหนึ่งเท่านั้น
แต่ทุกๆ คนต้องช่วยกันอ่าน requirement และ ถามคำถาม เพื่อทำให้มันชัดเจนขึ้น
และจะทำให้เราเห็นว่า ในความต้องหาร ความคาดหวังต่างๆ เหล่านั้น
มันต้องแลกมาด้วย เวลา และะ ค่าใช้จ่าย เท่าไร
เพื่อใช้ประกอบในการตัดสินใจต่อไป
แต่ข้อย้ำว่า ระบบจะต้องเร็วขึ้น เร็วขึ้น และ เร็วขึ้น อยุ๋อย่างเสมอครับ !!!
