Giá trị trung bình chẳng có ý nghĩa gì

• Sau khi triển khai tầng cache mới, độ trễ trung bình xấu đi từ 112ms lên 122ms, nhưng trung vị cải thiện từ 99ms xuống 54ms và p99 xấu đi từ 309ms lên 678ms, nên rất khó đánh giá thành bại chỉ bằng một giá trị thống kê duy nhất
• Sau khi triển khai, phân phối độ trễ tách từ một đỉnh thành hai đỉnh, và khi chồng hàm phân phối tích lũy (CDF) lên nhau có thể thấy lấy khoảng 140ms làm ranh giới, các request nhanh được cải thiện còn các request chậm thì xấu đi
• Hàm dịch chuyển thể hiện mức thay đổi theo từng phân vị cùng với đồ thị ridgeline và heatmap theo ngày cho thấy mức độ cải thiện và hồi quy, cũng như quá trình nhóm request chậm lớn dần khi tỷ lệ rollout tăng từ 0% lên 100%
• Khi chia dữ liệu theo kết quả cache và kích thước phản hồi, có thể xác nhận nguyên nhân tạo ra phân phối hai đỉnh: cache hit của phản hồi nhỏ nhanh hơn, còn cache miss của phản hồi lớn chậm hơn do thêm một hop
• Nếu chỉ chọn giá trị trung bình hoặc một phân vị cụ thể, thậm chí có thể biện minh cho những kết luận trái ngược nhau; vì vậy cần xem toàn bộ phân phối và các nhóm con cùng lúc để dẫn tới các biện pháp như tăng kích thước đối tượng tối đa trong cache hoặc tách nhỏ phản hồi lớn

---

Cải thiện hiệu năng không nhìn thấy trong production

• Các cải thiện hiệu năng liên quan đến lld xuất hiện trong benchmark, nhưng trên dashboard production thực tế thì rất khó tìm ra thay đổi rõ ràng vì nhiễu dữ liệu
• Tốc độ build có thể thay đổi lớn theo nhiều biến số như cold cache, incremental build, thực thi cục bộ/từ xa, trạng thái hệ thống và workload
• Từ trường hợp đánh giá hiệu năng build bằng hàm phân phối tích lũy (CDF), nảy sinh nhu cầu phải xem trực tiếp dữ liệu theo nhiều cách thay vì chỉ dựa vào một hình ảnh hay một giá trị thống kê
• Tất cả ví dụ đều được tạo từ một bộ dữ liệu tổng hợp duy nhất với seed cố định, và toàn bộ script có kèm shebang nix-shell, nên có thể tái hiện nguyên vẹn từng hình trong môi trường Nix
• AI đã được dùng để tạo dữ liệu phục vụ câu chuyện và sinh biểu đồ

Triển khai cache trông như thất bại nếu chỉ nhìn trung bình

• Để giảm độ trễ request của dịch vụ web, một tầng cache mới đã được triển khai trong một tuần, nhưng độ trễ trung bình lại tăng 9% từ 112ms lên 122ms
• Nếu chỉ nhìn giá trị trung bình, rất dễ kết luận đây là một hồi quy đủ để rollback thay đổi và bắt đầu ứng phó sự cố cùng phân tích hậu kiểm

Một bộ dữ liệu tạo ra bốn kết luận

• Các thống kê trước và sau triển khai chỉ theo những hướng khác nhau
  • Trung bình: 112ms → 122ms, xấu đi 9%
  • Trung vị p50: 99ms → 54ms, cải thiện 46%
  • p95: 224ms → 454ms, xấu đi 103%
  • p99: 309ms → 678ms, xấu đi 119%
• Giá trị trung bình cho thấy một hồi quy nhẹ, nhưng theo trung vị thì request điển hình gần như nhanh gấp đôi, còn theo p99 thì các request tệ nhất chậm hơn hơn gấp đôi, cho thấy một vấn đề nghiêm trọng
• Vì trung bình và trung vị tính từ cùng một bộ dữ liệu lại chỉ theo hai hướng trái ngược, nên rất dễ chọn ra chỉ số thống kê phù hợp với kết luận mình muốn bảo vệ

Hình dạng phân phối hé lộ hai nhóm request

• Trên đồ thị mật độ, phân phối trước triển khai có một đỉnh, nhưng sau triển khai lại tách thành hai đỉnh
• Hình dạng này giải thích mâu thuẫn giữa các giá trị thống kê, nhưng đồ thị mật độ cũng có những hạn chế
  • Hình dạng thay đổi theo tham số làm trơn được chọn
  • Khi vùng tô của hai phân phối chồng lấp nhau thì khó đọc
  • Có thể thấy sự tồn tại của hai nhóm, nhưng khó xác định ngay vị trí các phân vị như trung vị

So sánh toàn bộ phân vị bằng CDF

• Hàm phân phối tích lũy (CDF) cho biết với mỗi độ trễ x, tỷ lệ request hoàn thành trong x mili giây hoặc ít hơn
• Khi chồng CDF trước và sau triển khai lên cùng một biểu đồ, có thể thấy từng phân vị đã dịch chuyển thế nào trên toàn bộ tập request
• Sau triển khai, đường cong dịch sang trái ở vùng dưới 140ms nên nhiều request nhanh hơn trước, nhưng sau mốc 140ms thì nhiều request lại chậm hơn
• Điểm giao nhau của hai đường quanh 140ms là ranh giới nơi tác động của thay đổi chuyển từ cải thiện sang xấu đi
• Khi hai CDF cắt nhau, hướng tác động sẽ thay đổi tùy theo phân vị được chọn, nên không có bất kỳ một phân vị đơn lẻ nào có thể tóm tắt toàn bộ thay đổi

Đo mức thay đổi ở từng phân vị

• CDF cho thấy đoạn nào nhanh hơn hay chậm hơn, nhưng không trực tiếp thể hiện độ lớn của thay đổi
• Hàm dịch chuyển (shift function) tính chênh lệch giữa độ trễ sau triển khai và trước triển khai tại mỗi phân vị p
  • Dưới 0 là vùng được cải thiện
  • Trên 0 là vùng chậm đi
• Nhờ đó có thể thấy không chỉ hướng thay đổi mà cả mức độ của nó tại từng điểm trong phân phối

Hồi quy lớn dần trong quá trình rollout

• Tầng cache mới được mở rộng dần từ 0% đến 100% lưu lượng trong một tuần, nên nếu chỉ so sánh hai thời điểm trước và sau triển khai thì sẽ bỏ lỡ các biến đổi ở giữa
• Trên đồ thị ridgeline xếp chồng phân phối theo ngày, có thể thấy khi rollout tiến triển, đỉnh chính của các request nhanh dịch sang trái, còn đỉnh thứ hai của các request chậm xuất hiện ở phía phải
• Trong khi trung vị giảm xuống, số lượng request chậm và độ trễ của chúng lại âm thầm tăng lên
• Độ trễ có phân phối gần log-normal, nên trục x dùng thang log
  • Với trục tuyến tính, đỉnh của request nhanh vọt cao còn request chậm trải mờ ra, khiến khó đọc đồng thời cả hai đỉnh
• Trên heatmap thể hiện bằng màu lượng lưu lượng theo cột ngày và mức độ trễ, nhóm request mới cũng hiện ra một cách mờ nhạt
• Nếu gộp cả tuần thành một giá trị tổng hợp duy nhất, bảy phân phối theo ngày khác nhau và xu hướng thay đổi sẽ biến mất

Tách phân phối hai đỉnh theo cache hit và miss

• Trong phân tích lld thực tế, chỉ khi chia dữ liệu theo kích thước nhị phân, chẳng hạn trên 50MiB hay không, mới có thể thấy phân phối độ trễ hai đỉnh
• Trong ví dụ tổng hợp với tầng mới, request được chia thành hit khi được phục vụ từ cache và miss khi phải chuyển tới backend, đi qua thêm một hop
• Khi tách CDF của các request sau triển khai theo kết quả cache, mỗi nhóm lại chỉ còn một đỉnh
  • Cache hit dịch sang trái so với baseline cũ nên nhanh hơn
  • Cache miss nằm lệch hẳn sang phải vì chi phí của hop bổ sung

Tìm nguyên nhân và biện pháp từ kích thước phản hồi

• Cache miss chỉ là cơ chế vận hành; để hiểu request nào và vì sao gây ra miss, cần xem thêm kích thước phản hồi
• Cache giữ các đối tượng nhỏ và được dùng thường xuyên, còn đối tượng lớn thì bị đẩy ra hoặc không vào được ngay từ đầu
• Trên jointplot kết hợp mối quan hệ giữa độ trễ và kích thước phản hồi, tô màu theo cache hit/miss và thêm phân phối mật độ ở từng trục, hai nhóm hiện ra rất rõ
  • Nhóm phản hồi nhỏ, độ trễ thấp là cache hit
  • Nhóm phản hồi lớn, độ trễ cao là cache miss
• Phân phối độ trễ hai đỉnh bắt nguồn từ tính hai đỉnh của phân phối kích thước phản hồi, và có thể xử lý bằng cách tăng kích thước đối tượng tối đa trong cache hoặc tách nhỏ các phản hồi lớn

Nhìn toàn bộ phân phối thay vì chỉ một biểu đồ

• Một panel hay một biểu đồ đơn lẻ không đủ chứa toàn bộ bối cảnh, và trong một số trường hợp còn có thể dẫn tới phán đoán sai
• Cần quan sát cùng một bộ dữ liệu theo nhiều cách để hiểu đồng thời hình dạng phân phối, tác động theo từng phân vị, thay đổi theo thời gian, các nhóm con và nguyên nhân
• Đặc biệt, CDF rất hữu ích khi so sánh nhiều nhóm request mà vẫn thể hiện được toàn bộ phân phối trong một biểu đồ