Các chỉ số hiệu năng chính trong yêu cầu hiệu năng của hệ thống thông tin

1. Tổng quan

A. Định nghĩa

Là yêu cầu phi chức năng (NFR) định nghĩa mục tiêu hiệu năng mà hệ thống thông tin phải đáp ứng một cách định lượng và đo lường được. Được biểu đạt bằng các mục tiêu số như thời gian phản hồi·thông lượng, và trở thành tiêu chuẩn khách quan cho thiết kế·xây dựng·nghiệm thu·hợp đồng SLA.

Yêu cầu hiệu năng không quy định “làm gì (chức năng)” mà quy định “làm nhanh và ổn định đến mức nào (chất lượng)”. Dù đáp ứng yêu cầu chức năng, nếu hiệu năng kém thì hệ thống vẫn bị coi là thất bại — ví dụ, tra cứu được nhưng mất 30 giây thì người dùng sẽ không dùng hệ thống đó. Vì vậy hiệu năng phải được xử lý như một yêu cầu cốt lõi không kém chức năng.

B. Bối cảnh xuất hiện và sự cần thiết

Nếu yêu cầu hiệu năng chỉ dừng ở cách diễn đạt mơ hồ như “nhanh, ổn định” thì nhà phát triển·bên đặt hàng·bên nghiệm thu sẽ có kỳ vọng khác nhau, dẫn đến tranh chấp ở giai đoạn hoàn thành. Bởi vì tùy là “trong vòng 3 giây” hay “trong vòng 10 giây” mà số máy chủ và kiến trúc cần thiết hoàn toàn khác nhau. Chỉ số hiệu năng được định lượng (1) là căn cứ cho ước tính dung lượng và thiết kế kiến trúc, (2) cung cấp tiêu chí đạt của kiểm thử tải, và (3) cho phép phán định khách quan việc thực hiện SLA·nhiệm vụ. Đây là lý do yêu cầu hiệu năng phải được chốt bằng con số ngay từ đầu.

2. Các chỉ số hiệu năng chính

flowchart LR
  R[Thời gian phản hồi<br/>Cảm nhận người dùng] --- T[Thông lượng TPS<br/>Năng lực hệ thống]
  T --- C[Người dùng đồng thời<br/>Quy mô tải]
  C --- U[Mức sử dụng tài nguyên<br/>Dư địa·nút thắt]
  U --- A[Tính sẵn sàng<br/>Độ tin cậy]

Các chỉ số hiệu năng liên kết và biến động cùng nhau. Khi số người dùng đồng thời tăng thì yêu cầu thông lượng tăng, và khi thông lượng chạm giới hạn thì mức sử dụng tài nguyên bão hòa khiến thời gian phản hồi tăng vọt. Vì vậy các chỉ số phải được định nghĩa cùng nhau chứ không riêng lẻ.

• Thời gian phản hồi (Response Time): Thời gian từ khi người dùng gửi yêu cầu đến khi nhận được kết quả, phản ánh trực tiếp hiệu năng người dùng cảm nhận. Nếu chỉ dùng trung bình đơn thuần thì một số ít yêu cầu chậm bị che khuất, nên thực tiễn là định nghĩa theo bách phân vị (percentile) như “phân vị 95 trong vòng 3 giây”.
• Thông lượng (Throughput/TPS): Số lượng xử lý trên đơn vị thời gian (giao dịch mỗi giây), thể hiện khối lượng công việc (năng lực) hệ thống có thể gánh. Nếu thời gian phản hồi là góc nhìn từng yêu cầu thì thông lượng là góc nhìn xử lý tổng thể.
• Số người dùng đồng thời (Concurrency): Quy mô người dùng đang truy cập·được xử lý cùng thời điểm, định nghĩa độ lớn của tải. Phải phân biệt “người truy cập” và “người dùng hoạt động thực sự phát sinh yêu cầu” để tránh ước tính thừa·thiếu.
• Mức sử dụng tài nguyên (Utilization): Tỷ lệ sử dụng CPU·bộ nhớ·I/O đĩa·mạng, cho thấy dư địa và nút thắt. Thông thường đặt ngưỡng CPU 70~80% để vẫn còn dư địa khi tải đỉnh.
• Tính sẵn sàng (Availability): Chỉ số độ tin cậy được biểu đạt bằng tỷ lệ vận hành (VD: 99.9% → cho phép ngừng khoảng 8.8 giờ mỗi năm), được hỗ trợ bởi MTBF/MTTR.
• Khả năng mở rộng (Scalability): Năng lực duy trì hiệu năng bằng cách bổ sung tài nguyên khi tải tăng, quy định việc scale-up/out.

3. Các điểm cần lưu ý khi đặc tả

Mục tiêu hiệu năng chỉ có ý nghĩa khi được định nghĩa cùng với điều kiện đo lường. Bởi vì cùng con số “500 TPS”, mức độ khó đạt được hoàn toàn khác nhau tùy đó là lúc bình thường hay lúc đỉnh, khi dữ liệu có 100 nghìn bản ghi hay 100 triệu bản ghi. Vì vậy cần nêu rõ đồng thời các điểm sau.

• Nêu rõ điều kiện đo lường: Chốt làm tiền đề việc phân biệt đỉnh/bình thường, lượng dữ liệu tích lũy, mức độ đồng thời.
• Tính định lượng·khả năng kiểm chứng: Quy định đồng thời con số·đơn vị·giá trị mục tiêu và phương pháp đo lường, thống nhất đến cả “sẽ xác nhận bằng cách nào”.
• Tiêu chuẩn tải đỉnh: Với các hệ thống có lưu lượng tăng đột biến như quyết toán thuế cuối năm·đăng ký học phần, phải ước tính dựa trên thời điểm tải tối đa thì mới ngăn được sự cố thực tế.
• Liên kết SLA: Khớp các con số yêu cầu với mức dịch vụ đã ký hợp đồng (VD: tính sẵn sàng 99.9%, mục tiêu thời gian phản hồi) để làm rõ ranh giới trách nhiệm.

4. Phương pháp kiểm chứng

Mục tiêu đã định nghĩa nhất thiết phải được kiểm chứng bằng kiểm thử. Kiểm thử hiệu năng (tải) xác nhận việc đáp ứng chỉ số ở tải mục tiêu, kiểm thử căng thẳng (stress) xác nhận điểm giới hạn (tải tới hạn), kiểm thử độ bền (soak) xác nhận sự suy giảm như rò rỉ bộ nhớ khi vận hành trong thời gian dài. BMT (kiểm thử benchmark) so sánh các sản phẩm·kiến trúc ứng viên trong cùng điều kiện để kiểm chứng trước khả năng đạt mục tiêu, và ở giai đoạn vận hành, dùng APM giám sát thường xuyên chỉ số thực tế để phát hiện sớm vi phạm SLA.

5. Các điểm cần lưu ý và hàm ý

• Gắn trực tiếp với thiết kế: Yêu cầu hiệu năng quyết định ước tính dung lượng·kiến trúc (cache·cân bằng tải·đánh chỉ mục DB) nên phải được chốt ở đầu giai đoạn định nghĩa yêu cầu; thay đổi ở giai đoạn sau thì chi phí thiết kế lại rất lớn.
• Phân tích nút thắt và tinh chỉnh: Khi không đạt mục tiêu, thay vì tăng máy chủ một cách mù quáng, trước tiên hãy dùng profiling để tìm nút thắt (truy vấn chậm·tranh chấp khóa), rồi kết hợp scale-up/out với tinh chỉnh mã·truy vấn.
• Đánh đổi: Hiệu năng·chi phí·độ phức tạp mâu thuẫn nhau. Mục tiêu hiệu năng quá mức là lãng phí chi phí, nên cần xác định mức phù hợp dựa trên khối lượng công việc thực tế.
• Triển vọng·liên kết: Nhờ autoscale của đám mây và khả năng quan sát (Observability), quản lý hiệu năng đang được tự động hóa·thường xuyên hóa, và trong môi trường MSA, chỉ số theo từng dịch vụ và truy vết phân tán trở thành cốt lõi của quản lý hiệu năng.

Tóm tắt một câu: Yêu cầu hiệu năng là yêu cầu phi chức năng định nghĩa thời gian phản hồi·thông lượng (TPS)·người dùng đồng thời·mức sử dụng tài nguyên·tính sẵn sàng, v.v. một cách định lượng·có thể kiểm chứng cùng với tải đỉnh·điều kiện đo lường, là căn cứ cho ước tính dung lượng·kiến trúc và được kiểm chứng·quản lý bằng kiểm thử hiệu năng·BMT·APM.