Vì sao hệ thống IT chậm đi: cách đọc phân vị độ trễ thay vì giá trị trung bình để hiểu hiệu năng hệ thống

Hiệu suất IT thường trông vẫn ổn trên dashboard cho đến khi người dùng bắt đầu phàn nàn. Biểu đồ cho thấy thời gian phản hồi trung bình gần như không đổi, nhưng một số khách hàng lại phải chờ vài giây cho cùng một trang hoặc giao dịch. Khoảng lệch này rất phổ biến vì giá trị trung bình làm phẳng mọi khác biệt. Việc hiểu đúng cách phân vị phản ánh trải nghiệm chậm sẽ giúp nhìn ra những trường hợp mà con số tổng hợp đã che giấu.

Giá trị trung bình chỉ mô tả phần giữa, không phải lúc tệ nhất

Giá trị trung bình được tính bằng cách cộng tất cả thời gian phản hồi quan sát được và chia cho số lượng yêu cầu. Đó là một con số gọn để chia sẻ, nhưng nó dễ bị chi phối bởi số lượng lớn các yêu cầu nhanh. Nếu phần lớn yêu cầu hoàn thành nhanh và một nhóm nhỏ hơn phải chờ lâu, giá trị trung bình vẫn có thể trông ở mức chấp nhận được.

Hãy xét một dịch vụ xử lý 10.000 yêu cầu. Chín nghìn yêu cầu hoàn thành trong 100 mili giây, trong khi một nghìn yêu cầu mất 3 giây. Giá trị trung bình vào khoảng 390 mili giây, con số mà một số nhóm có thể cho là chấp nhận được. Tuy nhiên, cứ 10 người dùng thì có 1 người phải chờ ba giây. Giá trị trung bình không cho thấy sự phân tách n��y; nó chỉ mô tả tâm chung của dữ liệu.

Các yêu cầu chậm rất quan trọng vì người dùng không trải nghiệm con số tổng hợp. Mỗi người chỉ thấy kết quả của một yêu cầu duy nhất. Hệ thống có thể đạt mục tiêu trung bình nhưng vẫn tạo ra trải nghiệm khó chịu cho một nhóm khách hàng đáng kể.

Phân vị độ trễ cho thấy điều gì

Phân vị cho biết giá trị mà một tỷ lệ phần trăm nhất định các quan sát nằm dưới ngưỡng đó. Nếu độ trễ ở phân vị 95 là 2 giây, nghĩa là 95% yêu cầu hoàn thành trong 2 giây hoặc ít hơn, trong khi 5% còn lại mất nhiều thời gian hơn. Phân vị giúp phần đuôi chậm hiện rõ thay vì bị hòa lẫn vào một giá trị trung bình duy nhất.

Các lựa chọn phổ biến là trung vị, p90, p95 và p99. Trung vị là phân vị 50: một nửa số yêu cầu nhanh hơn và một nửa chậm hơn. p90 mô tả ngưỡng của 10% chậm nhất, p95 của 5% chậm nhất và p99 của 1% chậm nhất. Các phân vị càng cao càng tập trung vào những lần chờ hiếm gặp nhưng gây khó chịu nhiều nhất.

Phân vị đặc biệt hữu ích khi lưu lượng truy cập đa dạng. Một dịch vụ có thể phục vụ cả các lệnh gọi API nhanh và các yêu cầu báo cáo chậm hơn qua cùng một endpoint. Giá trị trung bình có thể thay đổi chỉ vì cơ cấu lưu lượng thay đổi, ngay cả khi không có luồng xử lý nào thực sự chậm đi. Các dải phân vị giúp phân biệt giữa việc chậm đi trên diện rộng và việc số lượng yêu cầu nặng tăng lên.

Đọc biểu đồ phân vị trong thực tế

Hãy bắt đầu bằng cách quan sát nhiều phân vị cùng lúc thay vì chỉ một con số. Một dashboard hữu ích có thể hiển thị p50, p95 và p99 cho cùng một endpoint trong cùng một khung thời gian. Trung vị cho thấy yêu cầu điển hình, trong khi p95 và p99 cho thấy phần đuôi tệ đến mức nào.

Hãy tìm các mẫu hình giữa ba đường này:

• Tất cả các phân vị cùng tăng: dịch vụ có thể đang chịu áp lực trên diện rộng, như bão hòa CPU, phụ thuộc chậm hoặc sự cố mạng.
• p50 giữ nguyên trong khi p95 và p99 tăng: một nhóm yêu cầu đang đi vào luồng chậm, như trượt cache, payload lớn hoặc một shard cụ thể.
• p99 tăng đột biến trong thời gian ngắn: các đợt tăng ngắn có thể đến từ dọn dẹp bộ nhớ (garbage collection), chờ pool kết nối, tự động mở rộng hoặc timeout tạm thời của dịch vụ phụ thuộc.
• Khoảng cách giữa p50 và p99 nới rộng: tính biến động đang tăng, ngay cả khi người dùng điển hình vẫn thấy hiệu năng tốt.

Những mẫu hình này chỉ là manh mối, không phải kết luận. Phân vị cho biết nên điều tra ở đâu; tự chúng không xác định được nguyên nhân.

Chọn phân vị phù hợp với tác động tới người dùng

Không có một phân vị nào đúng cho mọi hệ thống. Lựa chọn phù hợp phụ thuộc vào mức độ chậm mà sản phẩm có thể chấp nhận và số lượng người dùng bị ảnh hưởng.

Với công cụ nội bộ có lưu lượng thấp, p95 có thể đủ để phát hiện độ trễ đáng chú ý. Với dịch vụ tiêu dùng quy mô lớn, p99 có thể đại diện cho hàng chục nghìn yêu cầu mỗi phút, vì vậy sự cố ở p99 vẫn ảnh hưởng đến rất nhiều người. Với các luồng thanh toán hoặc xác thực, các nhóm thường theo dõi đồng thời p95 và p99 vì cả độ tin cậy và độ trễ phần đuôi đều quan trọng.

Việc đặt mục tiêu dưới dạng mục tiêu mức dịch vụ cũng rất hữu ích. Ví dụ, nhóm có thể đặt mục tiêu 95% yêu cầu hoàn thành trong 500 mili giây và 99% trong 1,5 giây. Điều này làm rõ trải nghiệm kỳ vọng và ngăn giá trị trung bình tốt che lấp phần đuôi xấu.

Đo toàn bộ hành trình, không chỉ một dịch vụ

Một yêu cầu của người dùng thường đi qua nhiều dịch vụ, cache, cơ sở dữ liệu và hàng đợi. Các thao tác nội bộ nhanh vẫn có thể tạo ra kết quả chậm ở đầu cuối khi một thành phần phụ thuộc phải chờ hoặc thử lại. Hãy đo độ trễ tại biên nơi người dùng chờ đợi, sau đó so sánh với thời gian của từng chặng.

Khi có thể, hãy truy vết cùng một yêu cầu qua các thành phần. Một trace có thể cho thấy dịch vụ chỉ tốn 80 mili giây cho xử lý nội bộ nhưng phải chờ 1,2 giây để lấy kết nối cơ sở dữ liệu. Phân vị giúp xác định những yêu cầu nào đáng để truy vết; còn trace giải thích thời gian đã đi đâu.

Hãy giữ khung thời gian đo nhất quán. p95 tính trên một phút có thể nhiễu khi lưu lượng thấp, trong khi khung thời gian quá dài có thể che giấu các sự cố ngắn. Kết hợp biểu đồ phân vị với lưu lượng yêu cầu và tỷ lệ lỗi để thay đổi lưu lượng không tạo ra kết luận sai lệch.

Những sai lầm thường gặp khi dùng phân vị

Các nhóm đôi khi lấy trung bình các giá trị phân vị giữa các máy chủ hoặc các khoảng thời gian. Cách này tạo ra con số khó diễn giải. Phân vị nên được tính từ các quan sát gốc hoặc được tổng hợp bằng phương pháp dành cho phân phối, chứ không phải lấy trung bình đơn giản.

Một sai lầm khác là chỉ theo dõi p50. Trung vị rất có giá trị, nhưng nó không nói gì về các yêu cầu chậm nhất. Sai lầm ngược lại là chỉ tập trung vào p99 và bỏ qua trung vị, điều này có thể che giấu tình trạng chậm trên diện rộng ảnh hưởng đến tất cả mọi người.

Cuối cùng, hãy nhớ rằng phân vị mô tả độ trễ, không phải nguyên nhân. Sự gia tăng đột ngột của p99 có thể do một lần triển khai, sự cố của dịch vụ phụ thuộc hoặc thay đổi kích thước yêu cầu. Hãy sử dụng mốc triển khai, chỉ số hạ tầng và trace để liên kết chuyển động của phần đuôi với một sự kiện cụ thể.

Cách thảo luận rõ ràng hơn về hiệu suất

Phân vị mang lại cho các nhóm một ngôn ngữ chung để thảo luận về trải nghiệm người dùng. Thay vì tranh luận liệu 400 mili giây có tốt hay không, họ có thể nói r���ng một nửa số yêu cầu hoàn thành nhanh trong khi 5% vượt ngưỡng mà khách hàng cảm nhận rõ. Cách diễn đạt này kết nối phép đo kỹ thuật với kết quả thực tế.

Hãy bắt đầu với trung vị để hiểu luồng điển hình, sau đó bổ sung p95 và p99 để lộ ra những trải nghiệm tệ. Theo dõi cách các dải này di chuyển theo thời gian, so sánh chúng với lưu lượng và lỗi, đồng thời dùng trace để điều tra phần đuôi chậm. Thói quen đơn giản này giúp những độ trễ ẩn hiện rõ và giúp đội ngũ IT khắc phục những vấn đề mà giá trị trung bình đã che giấu.