KRISS

Thinking About Performance

กระบวนการ design อะไรต่างๆนั้น ผมเห็นด้วยกับ Martin Fowler ว่าเราจะทำได้ดีเมื่อเรามีตัวเลือกเยอะๆ และเราเข้าใจ trade-off ต่างๆของตัวเลือกเหล่านั้น และเราก็เลือกมันมาใช้ให้เหมาะกับสถานการณ์

หลายๆครั้งในการออกแบบเราต้องตัดสินใจในสิ่งที่เกี่ยวข้องกับ performance หลายๆทีเรามักจะใช้วิธีเอาระบบขึ้นให้ได้ก่อน แล้วมา optimize ทีหลัง (ผมทำแบบนี้อยู่ ซึ่งกำลังคิดจะเปลี่ยน) หลายครั้งมัน work นะ แต่หลายๆครั้ง เราจะพบว่าบางตัวเลือกที่เราเลือกมา มันไม่เปิดโอกาสให้เรา optimize ทีหลังได้มากนัก และก่อให้เกิดปัญหา performance ตามมา

เราจะมาพูดถึงนิยามของ performance attribute ต่างๆกัน เพื่อใช้ในการคุยต่อในตอนต่อๆไป

Response time คือเวลาที่ระบบใช้ในการประมวลผลการร้องขอใดๆจากภายนอก เช่นการกดปุ่มอะไรซักอย่างบนหน้าจอ หรือ request บางอย่างที่ส่งมาจากโปรแกรมอื่น

Responsiveness คือความไวในการรับรู้การร้องขอ เทียบกับเวลาในการประมวลผล ถึงแม้ระบบจะมี response time ดี แต่ก็อาจทำให้ผู้ใช้ไม่พอใจถ้า responsiveness ไม่ดี ตัวอย่างเช่นถ้าเรากดปุ่มไปแล้วระบบเงียบไปจนกระทั่งประมวลผลเสร็จ อันนี้คือ responsiveness เป็นอันเดียวกับ response time แต่ถ้าพอกดปุ่มแล้วระบบแจ้งมาว่า รู้แล้วว่ากดปุ่ม และแสดง progress bar ให้ดูสักหน่อยระหว่างรอ ก็น่าจะดีขึ้น (ถึงแม้ response time จะเท่าเดิม)

Latency คือเวลาน้อยสุดที่ใช้ในการแสดงผลตอบกลับใดๆ (ไม่ว่างานที่สั่งให้ระบบทำจะคืออะไร แม้แต่สั่งให้ไม่ทำอะไร) ซึ่งมักจะนานเกินไปในระบบ remote ยกตัวอย่าง หากผู้ใช้สั่งให้โปรแกรมไม่ทำอะไร โปรแกรมจะโต้ตอบมาแทบจะทันทีบนเครื่องที่บ้าน แต่ถ้าเป็นเครื่อง remote ต้องใช้เวลา 2-3 วินาทีเพื่อจะตอบกลับ

อย่าสับสน response time-responsiveness-latency นะครับ สมมติเราโทรบอกเพื่อนให้คิดเลข 2 ครั้ง โจทย์เดียวกัน ครั้งแรกเพื่อนโทรมาตอบ ครั้งที่ 2 เพื่อนส่งจดหมายมาตอบ เวลาที่เพื่อนใช้คิดเลขคือ response time ส่วนเวลาในการโทร หรือส่งจดหมายคือ latency ครับ ส่วน responsiveness ก็คือ เพื่อนบอกเราว่า เฮ้ยคิดอยู่นะ อีก 2 นาทีเสร็จ

ในฐานะ application developer เรามักจะแก้ไขอะไรไม่ค่อยได้ในเรื่อง Latency ดังนั้นการป้องกันที่ง่ายที่สุด ก็คือการใช้ remote call ให้น้อยที่สุด พีเหรียด!

Throughput คือ ระบบทำงานได้มากเท่าไหร่ในเวลาหนึ่งๆ เช่นหากเรากำลัง copy ไฟล์ througput ก็จะวัดเป็น bps ส่วนกรณี Enterprise Application ก็อาจจะวัดเป็น transactions per second (tps) แต่ปัญหาก็จะอยู่ที่ transaction แต่ละอันมีความซับซ้อนต่างกัน ดังนั้นเราควรใช้ set ของ transaction ที่คล้ายๆกันในการวัด

คำว่า performance นั้นก็มักจะวัดกันแถวๆ response time หรือ throughput แล้วแต่เราจะเลือกอันไหน เพราะบางทีเราแก้เรื่อง throughput ให้มากขึ้น แต่ดันไปทำให้ response time สูงด้วย หรือบางทีหากเรามองมุมผู้ใช้ เขาอาจสนใจ responsiveness มากกว่า ดังนั้น เราอาจไปเพิ่ม responsiveness แทน (แม้ว่ามันอาจไปทำให้ throughput ลดลง หรือ response time เพิ่มขึ้น)

Load คือสิ่งที่บอกเราว่าระบบอยู่ภายใต้การใช้งานหนักหน่วง (stress) ขนาดไหน เช่นอาจวัดด้วยจำนวนผู้ใช้พร้อมกัน ซึ่ง load นี้มักจะใช้เป็นบริบท (context) ของการวัดอื่นๆเช่น response time เราก็จะกล่าวว่า response time ของระบบนี้คือ 0.5 วินาที ที่ 10 ผู้ใช้ และ 2 วินาที ที่ 20 ผู้ใช้

Load sensitivity คืออัตราการเปลี่ยนแปลงของ response time เทียบกับ load

เช่น ระบบ A มี response time 0.5 seconds ที่ 10 ถึง 20 ผู้ใช้ ส่วนระบบ B มี response time 0.2 วินาที ที่ 10 ผู้ใช้ และเพิ่มเป็น 2 วินาที ที่ 20 ผู้ใช้

ในกรณีนี้ระบบ B มี load sensitivity มากกว่า A หรือเราอาจใช้คำว่า degradation ก็ได้ โดยบอกว่า ระบบ B degrades มากกว่าระบบ A

Efficiency ความสามารถของระบบในการใช้ทรัพยากรให้เกิด performance

ระบบที่วัดได้ 30 tps ใช้ 2 CPUs ถือว่า efficient กว่าระบบที่ได้ 40 tps แต่ใช้ 4 CPUs

Capacity ของระบบคือ throughput หรือ load ที่มากที่สุดที่โปรแกรมจะยังทำงานอย่างมี performance ดี

Scalability คือการวัดที่บอกว่าการเพิ่มทรัพยากร (ส่วนใหญ่จะเป็น hardware) จะส่งผลต่อ performance อย่างไร

ระบบที่ scalable คือระบบที่เราสามารถเพิ่ม hardware เพื่อเพิ่ม performance ได้อย่างเป็นสัดส่วนตามกัน เช่นเพิ่มจำนวน server เป็น 2 เท่าแล้วทำให้ throughput เพิ่มเป็น 2 เท่า

vertical scalability หรือ scaling up คือการเพิ่มความแรงของ server เช่น อัดแรม อัด cpu ส่วน Horizontal scalability, หรือ scaling out คือเพิ่ม server

ในการทำ Enterprise Software นั้น เราน่าจะสนใจ Scalability มากๆเข้าไว้ เพราะการแก้ไขเรื่องอื่นๆเช่น capacity มักจะกินเวลาและเงินมากกว่าการเพิ่ม hardware ซึ่งเราเองอาจจะเคยด่าเรื่องนี้ตอนที่เราต้องเปลี่ยนคอมเพื่อเล่นเกมใหม่ๆ แต่ลองคิดดูดีๆ hardware ถูกลงเรื่อยๆ และที่สำคัญ มักจะถูกกว่าต้นทุนพัฒนา

ตอนนี้จบแค่นี้ก่อนครับ พบกันใหม่ ตอน 3
ครับ

ที่มา:
Patterns of Enterprise Application Architecture
ISBN:0-321-12742-0
ผู้เขียน:Martin Fowler

อ่านนี่ด้วยดิ:

• Patterns of Enterprise Application Architecture#1:Enterprise Application
• Patterns of Enterprise Application Architecture#4:The Three Principle Layers
• Patterns of Enterprise Application Architecture#3:Layering
• Response Time-Latency-Responsiveness
• What do I do next?