Định luật Little và Lý thuyết Hàng đợi

Định luật Little (Little's Law) là một trong những kết quả đẹp nhất của lý thuyết hàng đợi: nó đúng bất kể distribution của arrival hay service time, bất kể queue discipline (FIFO, LIFO, priority), và bất kể loại resource nào. Công thức đơn giản đến kinh ngạc:

L = λ × W

• L — số lượng request đang "in-flight" (đang được xử lý hoặc đang chờ trong queue)
• λ (lambda) — throughput hay arrival rate, đo bằng requests/second
• W — average latency, thời gian trung bình một request ở trong hệ thống

Ví dụ nhanh: nếu hệ thống nhận 1,000 req/s và mỗi request mất trung bình 200ms, thì tại mọi thời điểm có khoảng 200 request đang xử lý đồng thời. Điều đó nghĩa là bạn cần tối thiểu 200 worker slots — ít hơn sẽ gây backpressure và queue tích tụ.

Đây là nền tảng toán học cho mối quan hệ giữa latency, throughput và concurrency — ba đại lượng luôn ràng buộc lẫn nhau.

Little's Law có thể dùng theo cả ba chiều: biết hai đại lượng bất kỳ, suy ra đại lượng còn lại. Đây là công cụ thiết yếu trong capacity planning.

L = λ × W

# Trong đó:
#   L = số lượng request đang xử lý đồng thời (in-flight requests)
#   λ = throughput / arrival rate (requests per second)
#   W = average latency (thời gian xử lý trung bình)

# ── Example 1: Web API ──────────────────────────
λ = 1,000 req/s
W = 200ms = 0.2s
L = 1,000 × 0.2 = 200 concurrent requests
→ Cần tối thiểu 200 worker slots

# ── Example 2: Database connection pool ─────────
λ = 500 queries/s
W = 50ms = 0.05s
L = 500 × 0.05 = 25 connections needed
→ Pool size tối thiểu 25

# ── Example 3: Reverse capacity planning ────────
# Có 100 worker threads, muốn biết max throughput?
L = 100 workers
W = 0.1s (100ms average)
λ = L / W = 100 / 0.1 = 1,000 req/s max

Điều quan trọng cần nhớ: L, λ, W đều là giá trị trung bình trong steady-state. Nếu hệ thống chưa ổn định (ví dụ đang cold start hoặc traffic spike), công thức vẫn đúng về mặt giới hạn nhưng giá trị tức thời có thể dao động mạnh.

Một ứng dụng thường gặp là reverse capacity planning: cho biết số lượng worker và latency trung bình, ta tính được throughput tối đa hệ thống có thể xử lý trước khi queue bắt đầu tích tụ.

Utilization Law mở rộng Little's Law cho từng resource cụ thể:

ρ = λ × S — trong đó S là service time trung bình của resource đó.

Mô hình M/M/1 (Markovian arrival, Markovian service, 1 server) cho ta công thức response time khi có queuing:

R = S / (1 - ρ)

Khi ρ tiến gần 1, response time tăng theo đường cong hyperbolic — đây chính là "hockey stick curve" nổi tiếng. Biểu đồ bên dưới minh họa hệ số nhân latency tại các mức utilization khác nhau:

Tại ρ = 50%, latency chỉ gấp 2× service time thuần. Nhưng tại ρ = 95%, latency đã gấp 20×! Đây là lý do quy tắc vàng trong production:

Không bao giờ chạy production trên 70-80% utilization. Khoảng headroom 20-30% là buffer cần thiết để hấp thụ traffic burst mà không gây latency spike.

Amdahl's Law đặt giới hạn cứng cho speedup khi thêm parallel workers: nếu có σ (serial fraction) phần trăm công việc phải chạy tuần tự, thì dù thêm bao nhiêu worker, speedup tối đa chỉ là 1/σ.

Ví dụ: nếu 5% logic là serial (lock, shared state), speedup tối đa = 20×, bất kể có 1,000 hay 10,000 worker.

Universal Scalability Law (USL) của Neil Gunther bổ sung thêm yếu tố coherency penalty (κ) — chi phí communication và synchronization giữa các parallel worker. USL giải thích hiện tượng retrograde behavior: thêm worker quá nhiều thực tế làm giảm throughput vì overhead communication vượt quá lợi ích parallelism.

Hệ quả thực tiễn: đừng chỉ "scale thêm instance" một cách mù quáng. Cần đo contention (σ) và coherency (κ) để biết điểm sweet spot. Kỹ thuật Adaptive Concurrency Control giúp hệ thống tự tìm điểm tối ưu này tại runtime.

Little's Law và M/M/1 nói về giá trị trung bình, nhưng trong thực tế, chúng ta quan tâm đến tail latency — đặc biệt là P99. Mối liên hệ giữa utilization và percentile rất trực quan:

• Khi ρ tăng → queue dài hơn → P99 tăng trước, sau đó P95 theo, và cuối cùng P50 mới bị ảnh hưởng. P99 là "canary in the coal mine" cho saturation.
• Khi Coefficient of Variation (C) cao (service time biến thiên lớn) → distribution có tail dài hơn → gap giữa P50 và P99 lớn. Đây là dấu hiệu cần tách workload high-variance ra riêng.
• Chiến lược monitoring tối ưu: theo dõi ρ kết hợp P99 để phát hiện sớm nhất khi hệ thống đang tiến gần saturation point.

Tìm hiểu thêm về cách đo và interpret percentile tại Latency Percentile Metrics, và hiện tượng amplification tại Tail Latency at Scale.

Tổng hợp các định luật trên thành checklist actionable cho capacity planning:

1. Tính L (concurrent requests): Dùng Little's Law: L = λ × W. Đảm bảo worker pool, connection pool, thread pool đều ≥ L với buffer.
2. Giữ ρ < 70%: Tính utilization cho mọi resource (CPU, DB connections, disk I/O). Nếu ρ > 70%, cần scale out hoặc optimize service time.
3. Tách high-variance workloads: Nếu gap P50/P99 > 10×, cân nhắc tách workload có biến thiên cao ra queue riêng để không ảnh hưởng fast-path requests.
4. Set timeout trên mọi external call: Timeout chính là cách giới hạn W tối đa, từ đó giới hạn L tối đa. Không có timeout = cho phép L tăng không kiểm soát → cascading failure.
5. Đo contention trước khi scale: Dùng USL để xác định liệu thêm instance có thực sự giúp hay chỉ tăng coherency overhead.

Các kỹ thuật bổ trợ: Adaptive Concurrency Control giúp tự điều chỉnh concurrency limit tại runtime, và tổng quan Latency-Throughput cung cấp bức tranh toàn cảnh về mối quan hệ giữa các đại lượng.