Alice ไม่ชอบการรอคอย

 (brooker.co.za)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้เวลาเฉลี่ยของคำขอบริการจะอยู่ที่ 100ms และ MTTR จะต่ำกว่า 1 นาที ผู้ใช้ก็ยังรู้สึกว่า เวลาเฉลี่ยที่ต้องรอ นานกว่านั้นมาก เพราะพวกเขาติดอยู่กับคำขอที่ใช้เวลานานและเหตุขัดข้องที่ยาวนานนานกว่า
  • ผู้ดูแลระบบนับคำขอและเหตุขัดข้องเป็นหน่วยเหตุการณ์ แต่ผู้ใช้อย่าง Alice และ Alex คำนวณการรอคอยจาก เวลาที่รับรู้ได้จริงเป็นวินาทีและนาที
  • ความต่างนี้เกิดจาก inspection paradox โดยการกระจายที่ผู้ใช้ประสบไม่ใช่การกระจายความหน่วงเดิม f(t) แต่เป็นการกระจายที่ถ่วงน้ำหนักด้วย t
  • ในการกระจายแบบลอจ์นอร์มัลที่มีค่ามัธยฐานของเวลาฟื้นคืน 30 นาที และ p99 เท่ากับ 600 นาที แม้ MTTR จะมากกว่า 1 ชั่วโมงเพียงเล็กน้อย แต่เวลาเฉลี่ยในการฟื้นคืนที่ลูกค้ารับรู้ได้อาจเพิ่มขึ้นไปถึงประมาณ 6 ชั่วโมง
  • tail latency และเวลาฟื้นคืนที่ยาวนานสามารถครอบงำประสบการณ์ของลูกค้าได้ และค่าเฉลี่ยแบบตัดปลาย (trimmed mean) อาจเสี่ยงต่อการทิ้งข้อมูลสำคัญในหางขวา

ช่องว่างระหว่างค่าเฉลี่ยต่อคำขอกับค่าเฉลี่ยที่ผู้ใช้รับรู้

  • Alice ใช้เว็บบริการ และเหมือนคนส่วนใหญ่ เธอรับรู้เวลาเป็นวินาทีและนาที
  • ผู้ดูแลระบบอาจเห็นว่าคำขอเฉลี่ยเสร็จในเวลา 100ms แต่เวลาเฉลี่ยที่ Alice ต้องรออาจเป็น 1 วินาที
  • ความต่างแบบเดียวกันนี้เกิดขึ้นกับเหตุขัดข้องได้เช่นกัน
    • ผู้ดูแลระบบอาจบอกว่า MTTR ต่ำกว่า 1 นาที
    • แต่เวลาเหตุขัดข้องเฉลี่ยที่ Alex รับรู้อาจเป็น 1 ชั่วโมง
  • การวัดทั้งสองแบบสามารถถูกต้องได้พร้อมกัน
    • คำขอที่ใช้เวลานานหรือเหตุขัดข้องที่ยาวนาน นับเป็นเพียงเหตุการณ์เดียวในมุมของผู้ปฏิบัติการ
    • แต่ในมุมของเวลาใช้งานของผู้ใช้ มันมีน้ำหนักมากขึ้นตามระยะเวลาที่กินไป

การกระจายแบบถ่วงน้ำหนักด้วย t ที่เกิดจาก inspection paradox

  • ปรากฏการณ์นี้อธิบายได้ด้วย inspection paradox
  • ผู้ใช้ไม่ได้ประสบกับการกระจายความหน่วง f(t) โดยตรง แต่ประสบกับเวอร์ชันที่ถ่วงน้ำหนักด้วย t
  • เมื่อ MTTR หรือเวลาเฉลี่ยของคำขอเป็น E[X] ค่าเฉลี่ยที่ผู้ใช้ประสบจะเป็นดังนี้
    • E_a[X] = E[X²] / E[X]
    • E_a[X] = E[X] + Var(X) / E[X]
  • ยิ่งความแปรปรวนสูง ค่าเฉลี่ยที่ผู้ใช้รับรู้ก็จะยิ่งห่างจากค่าเฉลี่ยของตัวชี้วัดฝั่งปฏิบัติการมากขึ้น

ตัวอย่างค่ามัธยฐาน 30 นาทีและ p99 ที่ 600 นาที

  • หากใส่ค่าความหน่วงหรือเวลาฟื้นคืนที่ระดับค่ามัธยฐานและค่า 99th percentile ก็สามารถฟิตการกระจายแบบลอจ์นอร์มัล และเปรียบเทียบตัวชี้วัดของบริการกับค่าที่ลูกค้ารับรู้ได้
  • ค่าตัวอย่างมีดังนี้
    • ค่ามัธยฐาน TTR: 30 นาที
    • p99 TTR: 600 นาที กล่าวคือ ใน 100 เหตุการณ์ จะมี 1 เหตุการณ์ที่ใช้เวลาฟื้นคืน 10 ชั่วโมง
  • ในกรณีนี้ MTTR จะมากกว่า 1 ชั่วโมงเพียงเล็กน้อย แต่เวลาเฉลี่ยในการฟื้นคืนที่ลูกค้าประสบจะอยู่ที่ประมาณ 6 ชั่วโมง

กับดักของ tail latency และค่าเฉลี่ยแบบตัดปลาย

  • มีหลายเหตุผลที่ต้องทำความเข้าใจ tail latency และเวลาฟื้นคืนที่ยาวนาน และ multiple samples ก็เป็นหนึ่งในนั้น
  • ในเวลาการให้บริการ timeout-and-retry อาจช่วยซ่อนความหน่วงบางส่วนได้
    • อย่างไรก็ตาม คำขอที่กำลังทำงานต้องไม่ได้ครอบครอง lock หรือทรัพยากรแบบผูกขาดอื่นอยู่
  • แต่สำหรับเวลาฟื้นคืน การซ่อนแบบนี้ทำไม่ได้ ทำให้ ความหนาของหาง แสดงออกต่อประสบการณ์ลูกค้าโดยตรงมากกว่า
  • ค่าที่ตัดปลายอย่าง trimmed mean มีปัญหาตรงที่อาจบดบังลักษณะของหางขวาซึ่งครอบงำประสบการณ์ลูกค้า
  • อีกเหตุผลหนึ่งที่ไม่ชอบค่าที่ตัดปลายคือเรื่องที่เกี่ยวข้องกับ Little’s Law และการใช้ความจุ ซึ่งมีอธิบายไว้ใน บทความก่อนหน้านี้

ข้อควรระวังเกี่ยวกับการใช้การกระจายแบบลอจ์นอร์มัล

  • เลือกใช้การกระจายแบบลอจ์นอร์มัลเพื่อความสะดวกในการคำนวณเชิงตัวเลข
  • มันมีคุณสมบัติที่ lognormal(μ, σ²) กลายเป็น lognormal(μ + σ², σ²) และทำงานได้ดีใกล้ค่า 0
  • ไม่ได้หมายความว่าการกระจายแบบลอจ์นอร์มัลเป็นตัวเลือกที่ดีเป็นพิเศษสำหรับตัวชี้วัดความหน่วงหรือเวลาฟื้นคืน
  • โดยทั่วไปมองว่าปัญหาแบบนี้ควรเข้าหาด้วยวิธี ไม่อิงพารามิเตอร์ มากกว่า

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • น่าจะดีกว่าถ้าเปลี่ยนชื่อเป็นอะไรที่ให้ข้อมูลมากกว่านี้ เช่น Latency and the inspection paradox
    ชื่อปัจจุบันแทบจะให้ข้อมูลเป็นศูนย์เลย 😅

    • ในมุมของผู้เขียน ชื่อที่กำกวมสักหน่อยกลับมีประโยชน์พอสมควร
      เพราะช่วยลดคอมเมนต์ตอบกลับจากคนที่อ่านแค่ชื่อแล้วไม่ได้อ่านเนื้อหา

  • น่าสนใจ แต่ยังเข้าใจไม่ค่อยชัด เพราะผู้เขียนไม่ได้อธิบายว่าทำไมสิ่งนี้ถึงเป็นจริง นอกจากใช้คำว่า t-weighted กับสมการ
    อยากให้เขียนอธิบายให้ชัดกว่านี้หน่อย เพื่อให้คนที่ลืมวิชาสถิติระดับมหาวิทยาลัยไปนานแล้วก็ยังเข้าใจได้

    • สมมติว่ามีมอนิเตอร์ริงแดชบอร์ด โดยปกติเราจะปฏิบัติต่อทุกรีเควสต์เท่ากัน แล้วคำนวณค่า latency เฉลี่ยแบบนี้ 
      mean = (sum of all latencies) / (number of requests)
      นี่คือ E[X] และรีเควสต์แต่ละอันมีน้ำหนักเป็น 1/N
      ส่วน latency ที่ Alice รับรู้นั้นอิงตามเวลา เลยน่าจะเป็นที่มาของคำว่า ถ่วงน้ำหนักตามเวลา (time-weighted)
      ถ้า Alice ส่งรีเควสต์ M รายการที่มี latency เป็น x_1, x_2, ..., x_M เราก็สามารถถามว่า “ถ้าสุ่มเลือกเวลา 1 วินาทีจากช่วงเวลารอทั้งหมดของ Alice ในตอนนั้นรีเควสต์ที่กำลังรออยู่มี latency เท่าไร?”
      ในกรณีนี้ รีเควสต์ i จะมีสัดส่วนเป็น x_i / (Σ_j x_j) ดังนั้นรีเควสต์ที่นานกว่าจะถูกสะท้อนมากกว่า
      เพราะฉะนั้นค่าเฉลี่ยแบบถ่วงน้ำหนักตามเวลาจะเป็นดังนี้ 
      E_a[X] = Σ_i x_i (x_i / Σ_j x_j) = Σ_i x_i^2 / Σ_j x_j  
= (Σ_i x_i^2 / N) / (Σ_j x_j / N)  
= E[X^2] / E[X]
      ตัวอย่างง่าย ๆ คือ ถ้ามีรีเควสต์หนึ่งใช้เวลา 1 วินาที และอีกรีเควสต์ใช้เวลา 10 วินาที ค่าเฉลี่ยปกติคือ 5.5 วินาที แต่ค่าเฉลี่ยแบบถ่วงน้ำหนักตามเวลาจะเป็น 1 * (1 / 11) + 10 * 10 / 11 = 9.18s

  • ที่เกี่ยวข้องกัน The Inspection Paradox is Everywhere ก็น่าอ่านเหมือนกัน

  • ผมเองก็เคยคิดอะไรคล้าย ๆ กันในชีวิตจริง
    ผมว่าตัวอย่างที่เข้าใจปัญหานี้ได้ง่ายที่สุดคือการสำรวจถามผู้โดยสารรถบัสว่าบนรถมีคนอยู่กี่คน
    แบบนั้นคุณจะได้คำตอบแนว “รถแน่นมาก” บ่อยกว่ามาก แต่ตอนที่รถว่าง คุณจะไม่มีทางถามใครได้เลย
    อาจเป็นไปได้ว่ารถทุกคันว่างหมด และมีแค่คันเดียวที่คนแน่น
    ถ้าเป้าหมายคือการวิเคราะห์สถานการณ์จาก มุมมองของผู้ใช้ ผมคิดว่าสถิติแบบนี้ถูกต้องแล้ว

    • ในทฤษฎีกราฟก็มีผลลัพธ์คล้ายกัน คือเพื่อนของคนส่วนใหญ่มีเพื่อนมากกว่าตัวเอง
      เพราะโหนดที่มีการเชื่อมต่อมากจะปรากฏใน adjacency list ของโหนดอื่นบ่อยกว่าโหนดที่มีการเชื่อมต่อน้อย

  • ถ้าคุณรู้สึกว่าเรื่องนี้โดนใจ ขอแนะนำ Gil Tene's "How not to measure latency" อย่างมาก