Apdex (Chỉ số hiệu suất ứng dụng): Hướng dẫn kỹ thuật hoàn chỉnh & tiêu chuẩn số liệu

Apdex (Chỉ số hiệu suất ứng dụng) là một tiêu chuẩn công nghiệp mở được phát triển bởi liên minh các công ty phần mềm doanh nghiệp nhằm đo lường mức độ hài lòng của người dùng đối với thời gian phản hồi của các ứng dụng web và dịch vụ CNTT.

Thay vì chỉ dựa vào số liệu thời gian phản hồi trung bình hoặc phần trăm, Apdex chuyển đổi số liệu độ trễ kỹ thuật thành một điểm chuẩn duy nhất từ 0,0 (Không thể chấp nhận) đến 1,0 (Xuất sắc) phản ánh trực tiếp sự hài lòng của người dùng cuối.

Trả lời-Tóm tắt đầu tiên

Điểm Apdex chuyển đổi thời gian phản hồi của ứng dụng thành một số liệu chuẩn hóa duy nhất trong khoảng từ 0,00 đến 1,00 để đo lường mức độ hài lòng của người dùng.Yêu cầu được phân loại thành Hài lòng ($\le T$), Chấp nhận ($> T \text{ và } \le 4T$) và Không hài lòng ($> 4T$ hoặc lỗi HTTP 5xx) dựa trên thời gian phản hồi được nhắm mục tiêu $T$ (thường là 200 mili giây đến 500 mili giây).Công thức là $\text {Apdex} _T = (\text {Satisfied} + (\text {Tolerating} / 2)) / \text{Tổng số mẫu}$.Điểm Apdex trên 0,94 thể hiện hiệu suất xuất sắc, trong khi điểm dưới 0,70 cho thấy sự thất vọng nghiêm trọng của người dùng cần phải tối ưu hóa kỹ thuật ngay lập tức.

Cách tính điểm Apdex

Tính toán Apdex phân loại mọi yêu cầu của người dùng thành một trong ba vùng hiệu suất riêng biệt dựa trên ngưỡng mục tiêu thời gian phản hồi được xác định $T$ (chẳng hạn như $200\text {ms} $):

Hài lòng: Yêu cầu có thời gian phản hồi $\le T$.Người dùng trải nghiệm khả năng phản hồi tối ưu và tiến hành các quy trình công việc mà không do dự.
Dung lượng: Yêu cầu có thời gian phản hồi $> T$ và $\le 4T$.Người dùng nhận thấy có độ trễ nhỏ nhưng có thể hoàn thành nhiệm vụ của mình mà không cần rời khỏi ứng dụng.
Thất vọng: Yêu cầu có thời gian phản hồi $> 4T$ hoặc yêu cầu dẫn đến lỗi HTTP (mã trạng thái 5xx).Người dùng gặp phải tình trạng chậm chạp không thể chấp nhận được hoặc dịch vụ bị hỏng hoàn toàn.

Công thức toán học cho điểm Apdex được biểu thị như sau:

$$\text {Apdex} _T = \frac{\text{Số lượng hài lòng} + \frac{\text{Số lượng dung sai}}{2}}{\text{Tổng số mẫu}}$$

Ví dụ toán học đã làm việc

Hãy xem xét một ứng dụng SaaS nhận được 10.000 yêu cầu trong khoảng thời gian giám sát kéo dài một giờ với ngưỡng mục tiêu $T = 200\text {ms} $:

Yêu cầu được đáp ứng ($\le 200\text {ms} $): 8.500
Dung lượng các yêu cầu ($200\text {ms} < t \le 800\text {ms} $): 1.000
Yêu cầu không thành công ($> 800\text {ms} $ hoặc lỗi 5xx): 500

Việc thay các giá trị này vào công thức Apdex sẽ mang lại:

$$\text {Apdex} _ {200} = \frac{8500 + \frac {1000} {2}} {10000} = \frac{8500 + 500} {10000} = \frac{9000} {10000} = 0,90$$

Điểm Apdex là 0,90 thuộc loại Tốt, cho thấy rằng mặc dù hầu hết người dùng đều thích trải nghiệm nhanh nhưng 15% yêu cầu gặp phải độ trễ hoặc lỗi cần tối ưu hóa.

Thang xếp hạng Apdex & Hạng mục điểm

Liên minh Apdex xác định năm dải xếp hạng được tiêu chuẩn hóa để chuyển điểm số thành các mục tiêu kỹ thuật có thể thực hiện được:

Phạm vi điểm Apdex	Đánh giá hiệu suất	Đánh giá trải nghiệm người dùng	Cần hành động chiến lược
$0,94 - 1,00$	Tuyệt vời	Hiệu suất tối ưu trên hầu hết các yêu cầu của người dùng.	Duy trì năng lực hiện có và theo dõi đường cơ sở hồi quy.
0,85$ - 0,93$	Tốt	Khả năng phản hồi cao với độ trễ không thường xuyên.	Tối ưu hóa các truy vấn cơ sở dữ liệu và nén nội dung.
0,70$ - 0,84$	Công bằng	Tắc nghẽn hiệu suất ảnh hưởng đến một bộ phận người dùng đáng chú ý.	Tiến hành lập hồ sơ CPU/bộ nhớ và bật bộ nhớ đệm biên CDN.
0,50$ - 0,69$	Nghèo	Sự thất vọng của người dùng cao;yêu cầu tối ưu hóa hiệu suất ngay lập tức.	Mở rộng quy mô các nút cơ sở hạ tầng và công cụ tái cấu trúc chặn các tác vụ của luồng chính.
$< 0,50$	Không thể chấp nhận	Tình trạng chậm chạp hoặc ngừng dịch vụ trên diện rộng.	Thực hiện ứng phó sự cố khẩn cấp và điều tra tình trạng bế tắc của cơ sở dữ liệu.

Chọn đúng ngưỡng mục tiêu $T$

Việc chọn ngưỡng mục tiêu thích hợp $T$ là rất quan trọng để đạt được điểm Apdex có thể thực hiện được.Nếu $T$ được đặt quá cao (ví dụ: $2000\text {ms} $), các yêu cầu chậm sẽ bị phân loại sai là Hài lòng.Ngược lại, nếu $T$ được đặt quá thấp (ví dụ: $20\text {ms} $), độ trễ mạng thông thường sẽ làm giảm điểm ứng dụng của bạn một cách không cần thiết.

Ngưỡng mục tiêu được đề xuất theo loại ứng dụng:

API và vi dịch vụ: $T = 100\text {ms} - 200\text {ms} $
Ứng dụng web SaaS tương tác: $T = 200\text {ms} - 400\text {ms} $
Trang sản phẩm thương mại điện tử: $T = 300\text {ms} - 500\text {ms} $
Nền tảng nội dung và đa phương tiện: $T = 500\text {ms} - 1000\text {ms} $

Tại sao Apdex lại vượt trội hơn thời gian phản hồi trung bình

Các công cụ giám sát truyền thống thường xuyên báo cáo thời gian phản hồi trung bình.Tuy nhiên, số liệu trung bình có thể gây hiểu nhầm lớn vì những lý do sau:

Độ lệch ngoại lệ: Một số lượng nhỏ thời gian chờ quá 30 giây có thể tăng giả tạo thời gian phản hồi trung bình của hàng nghìn yêu cầu nhanh 50 mili giây, tạo ra cảnh báo sai.
Phân phối hai chiều: Khi một ứng dụng phân phát nội dung tĩnh được lưu trong bộ nhớ đệm trong 10 mili giây và các truy vấn cơ sở dữ liệu phức tạp không được lưu vào bộ nhớ đệm trong 2000 mili giây, thì mức trung bình 1005 mili giây không thể hiện chính xác trải nghiệm của người dùng.
Chuẩn hóa lấy người dùng làm trung tâm: Apdex chuẩn hóa các số liệu phản hồi thành điểm số 0 đến 1 dễ hiểu đối với con người mà các bên liên quan phi kỹ thuật, người quản lý sản phẩm và giám đốc điều hành có thể theo dõi theo thời gian mà không cần chuyên môn sâu về đo từ xa.
Trọng số lỗi: Apdex tự động xử lý các lỗi máy chủ HTTP 5xx và hết thời gian chờ mạng dưới dạng các yêu cầu Thất vọng, ghi lại các lỗi khả dụng ngay bên trong chỉ mục hiệu suất.

Apdex so với Core Web Vitals (LCP & INP)

Mặc dù Apdex ban đầu được phát triển cho thời gian phản hồi phía máy chủ và các công cụ APM, nhưng kỹ thuật hiệu suất web hiện đại yêu cầu kết hợp Apdex với Core Web Vitals của Google:

Apdex: Đo thời gian phản hồi của máy chủ phụ trợ và độ trễ xử lý API trên tất cả các yêu cầu HTTP.
Mức độ hiển thị nội dung lớn nhất (LCP): Đo tốc độ tải hình ảnh ở giao diện người dùng khi phần tử nội dung lớn nhất kết thúc hiển thị trong khung nhìn của người dùng.
Tương tác với Sơn tiếp theo (INP): Đo lường khả năng phản hồi của giao diện người dùng giao diện người dùng trong quá trình tương tác của người dùng (nhấp chuột, nhấn và nhấn phím).

Bằng cách theo dõi Apdex cho các điểm cuối API Go/Gin phụ trợ của bạn cùng với LCP và INP cho ứng dụng Nuxt 4 giao diện người dùng của bạn, các nhóm kỹ thuật đạt được khả năng hiển thị từ đầu đến cuối trên cả hiệu suất phía máy chủ và phía máy khách.

Tích hợp Apdex vào quy trình giám sát liên tục

SimpleOps tự động theo dõi điểm Apdex trên tất cả các điểm cuối HTTP đã đăng ký, tuyến ứng dụng web và vi dịch vụ API của bạn.Bằng cách kết hợp ping thăm dò tổng hợp từ hơn 15 vị trí kiểm tra toàn cầu với phép đo từ xa của người dùng thực, SimpleOps sẽ cảnh báo cho nhóm kỹ thuật của bạn thông qua Slack, Telegram hoặc Webhooks bất cứ khi nào điểm Apdex của ứng dụng của bạn giảm xuống dưới ngưỡng SLO đã định cấu hình của bạn.

Bằng cách giám sát Apdex cùng với thời gian hoạt động tổng hợp và Core Web Vitals, các nhóm DevOps có được thông tin đầy đủ về cả tính khả dụng và chất lượng hiệu suất trên toàn bộ nhóm người dùng toàn cầu, ngăn chặn tình trạng khách hàng rời bỏ và bảo vệ doanh thu kinh doanh.