เชื่อว่าหลายคนอาจจะเคยได้ยินคำว่า latency กับ throughput มาบ้างแล้ว แต่อาจยังไม่แน่ใจว่ามันคืออะไร และมันแตกต่างกันยังไง ในทาง Software Engineering สองสิ่งที่เรียกได้ว่าหนึ่งในเป็นหน่วยวัดพื้นฐานของการทำ Software System เลย วันนี้เราจะมาศึกษาเรื่องนี้กัน
เพื่อความง่ายต่อการเข้าใจ เราจะใช้ server/client model ประกอบการอธิบาย
- Client เช่น laptop หรือ mobile devices ต่างๆ ที่จะทำการเข้าถึง resources จาก server
- Server ซึ่งจะทำหน้าที่ประมวลผลสิ่งที่ client ทำการร้องขอเข้ามาแล้วส่ง response กลับไป
Latency
Terminology: latency = how long do customers have to wait for a pizza
ปกติเวลาที่เราเข้าหน้าเว็บไซต์ต่างๆ web browser (client) จะทำการ request ไปที่ server และเมื่อ server ได้รับ request แล้วจะทำการประมวลผลสิ่งที่ขอเข้ามาเช่น html หรือ json data (ในกรณีที่ request เป็น API) และเมื่อ server ทำการประมวลผลสิ่งที่ขอเข้ามาแล้ว server จะส่งสิ่งที่ต้องการกลับไปหา client ซึ่งเมื่อ client ได้รับแล้วถือว่าเป็นอันจบกระบวนการ เราเรียกเวลาทั้งหมดที่ใช้ตั้งแต่ client ทำการ request จนได้ response กลับไปว่า Latency ซึ่งปกติจะนับเป็นหน่วย millisecond (ms)
โดย Latency คือช่วงเวลาทั้งหมด ซึ่งเกิดจากการรวมของ Latency ย่อย 2 ประเภทก็คือ Request Processing Latency กับ Queueing Latency
Total Latency = Request Processing Latency + Queueing Latency
ในทางปฏิบัติแล้ว เราต้องการที่จะให้ Latency มันน้อยที่สุดเท่าที่จะเป็นไปได้ เลขนี้ยิ่งน้อยยิ่งดี ตัวเลขยิ่งน้อยแปลว่า client ใช้เวลาเล็กน้อยในการรอ ซึ่ง improve user experience ในทางตรงกันข้าม ถ้า Latency เยอะ แปลว่าใช้เวลานานกว่า client จะได้รับสิ่งที่ร้องขอไป เช่นใช้ บางเว็บไซต์ใช้เวลาโหลดหน้าแรก ทำให้ user ต้องรอนานกว่าจะเห็นหน้าเว็บจริงๆ
1. Request Processing Latency
หรือเรียกอีกชื่อคือ Intrinsic latency เป็นเวลาที่ฝั่ง Server ใช้สำหรับการประมวลผล แล้วส่ง response กลับไปยัง client ซึ่งจะนับจากตอนที่ request ถูกส่งไปถึง server แล้วจริงๆ จะไม่นับช่วงเวลาก่อนหน้าที่อาจจะถูกใช้ไปสำหรับการรอคิวก่อนที่ request จะเดินทางมาถึง server
สำหรับเวลาที่ server ใช้ประมวลผลมีทั้งแบบ 1) I/O bound operation เช่นการติดต่อและดึงข้อมูลจากฐานข้อมูล (query from database) หรือการเรียก external service และ 2) CPU bound operation เช่นการเขียนวนลูป ซึ่งอาจจะใช้เวลานานสำหรับเคสของ nested loop (O(n^2)) ในกรณีที่ array มีขนาดใหญ่ๆ
2. Queueing Latency
Queueing Latency หรือ Queueing Delay คือช่วงเวลาที่ request ถูกพักไว้ใน queue ก่อนที่ request นั้นจะถูกส่งไปถึง server ซึ่งในช่วงปกติที่มี request เข้ามาในระดับที่ server สามารถรองรับได้ (ไม่เกิน maximum throuput ซึ่งจะกล่าวถึงในหัวข้อถัดไป) เวลา queueing latency จะเป็น 0 เพราะ request ถูกส่งมาแล้ว forward ไปถึง server โดยทันที แต่ถ้าในช่วง peak hours ที่ระบบเรามี request เข้ามาเกินกว่าที่ server จะรับไหว request บางส่วนจะต้องเข้าคิวรอก่อนที่จะไปถึง server (ตามรูปด้านบน)
ในความเป็นจริงแล้ว Request Processing Latency กับ Queueing Latency ไม่ได้มีความสัมพันธ์กันโดยตรง ในบางสถาณการณ์เราอาจเจอเหตุการที่ Queueing Latency สูงแต่มี Request Processing Latency ต่ำ ยกตัวอย่างจากในชีวิตประจำวันก็เช่น เวลาที่เราต่อคิวยาวเหยียดเพื่อเข้าชมคอนเสิร์ต เราใช้เวลารอคิวนานแต่พอถึงหน้าประตูจริงๆ เราแค่โชว์บัครแล้วพนักงานก็ให้เข้าได้เลยซึ่งใช้เวลาน้อยมาก ถ้าเทียบกับเวลาที่ต้องยืนคอยในแถว
Throughput
Terminology: throughput = how many pizzas does the shop can make in a certain time period
ตือจำนวนหน่วยหรือ unit ที่ server สามารถรองรับ request ได้ ณ ช่วงเวลาใดเวลาหนึ่ง โดย unit อาจจะเป็น ขนาดของ request (KB/MB) หรือจำนวนของ request เอง (number of requests) ซึ่งในโพสนี้ผมขอใช้จำนวนของ request เป็นหน่วยในการวัด throughput
ตัว throughput ส่วนใหญ่จะวัดกันที่ระดับวินาที เช่น requests/queries per second (RPS or QPS) ปกติเวลาเราพูดถึง throuput ส่วนใหญ่เราจะเน้นไปที่ maximum throughput ซึ่งคือจำนวนที่มากที่สุดที่ server สามารถ handle request ได้โดยไม่กระทบกับ server แต่ถ้ามี request มากกว่า maximum throughput อาจทำให้ระบบเรารองรับไม่ไหว ทำให้ client อื่นที่ทำการ request เข้ามาต้องรอ ซึ่งเวลาที่ใช้ในการรอคิวก็คือ Queueing Latency ที่เราเล่าไปแล้วข้างบนนั่นเอง
การคำนวณ Throughput
การรู้ว่าระบบเราสามารถรอง request พร้อมกันได้เท่าไร เป็นสิ่งที่จำเป็นมากๆ เพราะจะช่วยให้เราตัดสินใจเวลาที่เราออกแบบระบบ หรือเวลาที่ต้อง scale ระบบเพื่อรองรับ request ที่มากขึ้น ช่วยให้เราไม่ underestimate หรือ overestimate request มากเกินความเป็นจริง โดยการคำนวณ max throughput จะคิดจาก
Max throughput = no. of request handlers / request processing latency
ก็คือเอา unit of request handlers เช่น จำนวน thread หรือจำนวน requests ที่ระบบเราสามารถจัดการได้พร้อมกัน ณ ช่วงเวลาหนึ่ง หารด้วยเวลาที่ใช้ในการประมวณผล (ใช้เป็นค่าเฉลี่ยได้)
ตัวอย่าง: สมมติว่าระบบเรามี 4 threads สำหรับรองรับ request และแต่ละ request ใช้เวลาเฉลี่ยประมาณ 500ms (ครึ่งวินาที) maximum throuput ของเราจะเท่ากับ 4/0.5 = 8 requests per second
อีกตัวอย่างแบบ non-technical: สมมติว่าร้านอาหารตามสั่งของเรามีแม่ครัว 3 คน และในการผัดกะเพราหนึ่งจานแม่ครัวจะใช้เวลา 1 นาที ดังนั้น maximum throuput ของเราจะเท่ากับ 3/1 = 3 units per minute ซึ่งแปลว่าในหนึ่งนาทีเราจะได้ผัดกะเพรา 3 จาน 🌶🌶🌶
Latency สูงขึ้นต้องทำยังไง
ถ้าวันดีคืนดี อยู่ๆ latency ของระบบเราพุ่งเกินค่าปกติ (latency spike) ทีนี้เราอยากรู้สาเหตุว่ามันเกิดมาจากอะไร Latency อยากรู้ว่าที่มันเพิ่มขึ้นมานั้นมาจาก Request Processing Latency หรือ Queueing Latency เพื่อที่จะได้แก้ถูกจุด สิ่งที่ควรทำอันดับแรกคือต้องดู Throughput ประกอบด้วย (ปกติสามารถดูได้จาก monitoring tool ของ cloud provider) ซึ่งอาจเป็นไปได้ 2 กรณี
1. Latency Spike - Throughput constant
ถ้า Latency สูงขึ้น แต่ Throuput คงที่ ไม่เพิ่มไม่ลด แปลว่า server เราสามารถ handle request ได้ปกติ (อาจจะกำลัง handle at max throughput) แต่เป็นทางฝั่ง request ที่เข้ามาเพิ่มมากขึ้นผิดปกติ ทำให้บาง request ต้องรออยู่ในคิว ซึ่งส่งผลทำให้ Queueing Latency เพิ่มสูงขึ้น ทำให้ Total Latency ของระบบเพิ่มสูงขึ้น
ถ้าเป็นเคสนี้เราสามารถเพิ่ม capacity ของระบบเรา ด้วยการ scale ให้รองรับ request ได้มากขึ้น (เพิ่มแม่ครัวมาช่วยผัดกะเพรา) ทำให้ request ที่รออยู่ในคิวนั้นลดลง และจะค่อยๆกลับไปอยู่ในจุดปกติ ก่อนเกิดการ spike
2. Latency Spike - Throughput drop
อีกกรณี คือถ้า Throughput ลดลงในขณะที่ Latency พุ่งสูงขึ้นแปลว่า server เราตอนนี้สามารถจัดการกับ request ได้น้อยลงกว่าช่วงปกติ ยกตัวอย่างเช่นตอนช่วงปกติ throughput อยู่ที่ 15 RPS แต่อยู่ดีๆ latency spike และ throughput ลดลงมาเหลือแค่ 5 RPS เคสนี้แปลว่ามีอะไรผิดปกติที่ฝั่ง server ของเรา ทำให้ใช้เวลานานมากขึ้นกว่าปกติในการ handle 1 request
ซึ่งเคสนี้ Latency ที่เกิดขึ้นไม่ได้มาจาก Queueing Latency แต่มาจาก Request Processing Latency ในฝั่งของ server เรา เคสนี้ไม่สามารถ scale up เพื่อแก้ปัญหาได้ ต้องไป investigate ดูต่อว่ามีอะไรผิดปกติ
จะเห็นได้ว่าถ้าเราสามารถ identify ได้ว่า Latency ที่เพิ่มขึ้นมานั้นมาจากส่วนไหน มาจากปัจจัยทางฝั่ง client (Queueing Latency) หรือ ฝั่ง server (Request Processing Latency) จะช่วยทำให้เราแก้ปัญหาได้ถูกจุด
สรุป
หวังว่าบทความนี้จะช่วยให้พอเห็นภาพมากขึ้นนะครับ จริงๆ ที่กล่าวไปเป็นเพียงปัจจัยบางส่วนเท่านั้นนะครับ ในระบบจริงมันมีปัจจัยอื่นมาเกี่ยวข้องด้วย ไม่ว่าจะเป็น ระยะทาง (geographical distance) จาก client ไปจนถึง server หรือจะเป็นเรื่องของการที่มีหลายๆ service ทำงานร่วมกัน ในระบบที่เป็น microservice ซึ่งแน่นอนว่าการวัด Latency จะต้องพิจารณาเรื่องนี้เข้ามาเกี่ยวด้วย
Reference: