Độ trễ hệ thống ảnh hưởng hiệu suất như thế nào?

Ở phạm vi một hệ thống công nghệ hoàn chỉnh, độ trễ rộng hơn độ trễ mạng. Một yêu cầu có thể phải chờ truyền dữ liệu, xếp hàng, xử lý CPU, truy vấn cơ sở dữ liệu, đọc ghi lưu trữ, gọi dịch vụ bên ngoài rồi mới trả kết quả. Vì vậy, một máy chủ xử lý nhanh chưa chắc tạo ra trải nghiệm nhanh nếu các thành phần còn lại trong chuỗi có latency lớn.

Độ trễ hệ thống được hình thành như thế nào?

Có thể hình dung độ trễ đầu cuối của một yêu cầu bằng phép phân rã:

Latency tổng ≈ truyền mạng chờ hàng đợi xử lý ứng dụng truy cập dữ liệu dịch vụ phụ thuộc xử lý phía người dùng

Đây là mô hình phân tích, không phải công thức cộng tuyệt đối cho mọi kiến trúc. Các tác vụ chạy song song có thể chồng thời gian lên nhau, cache có thể bỏ qua một số bước, trong khi retry hoặc xử lý tuần tự lại làm thời gian tăng thêm.

Ví dụ, người dùng nhấn nút thanh toán. Yêu cầu phải đi từ thiết bị tới máy chủ, qua API gateway, chờ một worker nhận việc, đọc thông tin đơn hàng trong cơ sở dữ liệu, gọi dịch vụ thanh toán rồi gửi kết quả trở lại trình duyệt. Nếu các bước tuần tự mất lần lượt 30 ms, 20 ms, 60 ms, 80 ms và 100 ms, thời gian chờ đã đạt khoảng 290 ms trước khi tính thêm các công việc phía trình duyệt.

Khoảng cách vật lý cũng tạo ra giới hạn thực tế cho latency mạng. Dữ liệu Internet thường phải đi qua nhiều mạng và thiết bị định tuyến; mỗi chặng xử lý hoặc định tuyến đều có thể bổ sung thêm thời gian. Vì vậy, đặt ứng dụng ở xa người dùng có thể làm phản hồi chậm dù máy chủ còn nhiều tài nguyên.

Độ trễ đặc biệt tăng mạnh khi hệ thống gần trạng thái bão hòa. Khi CPU, connection pool, worker, database connection hoặc I/O không còn đủ khả năng phục vụ yêu cầu ngay lập tức, request bắt đầu xếp hàng. Thời gian xử lý thực tế có thể chưa thay đổi nhiều nhưng thời gian chờ trước khi được xử lý tăng lên, khiến latency đầu cuối tăng nhanh.

Độ trễ cao làm giảm hiệu suất ra sao?

Tác động trực tiếp nhất là kéo dài response time. Nếu một thao tác vốn mất 100 ms nhưng phải gọi tuần tự ba dịch vụ có thêm 100 ms latency mỗi dịch vụ, phần thời gian chờ có thể lớn hơn chính thời gian xử lý nghiệp vụ.

Trong hệ thống phân tán, vấn đề còn rõ hơn khi một request phụ thuộc vào nhiều backend. Một nhánh phản hồi chậm có thể giữ toàn bộ kết quả lại dù những nhánh khác đã hoàn thành. Nếu ứng dụng còn thực hiện retry khi gặp timeout, một lần chậm có thể sinh thêm request, tăng tải và tiếp tục làm hàng đợi dài hơn.

Latency cũng có quan hệ với throughput nhưng hai khái niệm không đồng nhất. AWS phân biệt latency là thời gian cần để dữ liệu hoặc yêu cầu hoàn thành, còn throughput phản ánh lượng dữ liệu thực tế được xử lý trong một khoảng thời gian. Một hệ thống có băng thông lớn vẫn có thể phản hồi chậm, và một hệ thống phản hồi rất nhanh cho từng request chưa chắc xử lý được khối lượng request lớn.

Điểm khác biệt này quan trọng khi đánh giá hiệu suất:

Do đó, tăng CPU hoặc tăng bandwidth không phải lúc nào cũng giải quyết được độ trễ. Cần xác định thành phần nào thực sự giữ request lâu nhất.

Tại sao latency ảnh hưởng trực tiếp đến trải nghiệm sử dụng?

Người dùng cảm nhận hiệu suất thông qua thời gian từ hành động đến phản hồi, không thông qua số lượng CPU core hay thông lượng nội bộ của hệ thống. Một API có throughput cao vẫn tạo cảm giác chậm nếu thao tác nhấn nút, tìm kiếm hoặc chuyển trang phải chờ quá lâu.

Đối với web, Interaction to Next Paint (INP) là một ví dụ về cách đo khả năng phản hồi theo trải nghiệm thực tế. Theo web.dev, INP ở phân vị thứ 75 không quá 200 ms được xếp vào mức phản hồi tốt; từ trên 200 đến 500 ms cần cải thiện và trên 500 ms được xem là kém. Đây là benchmark dành cho tương tác web, không phải ngưỡng chung áp dụng cho mọi API, database hoặc hệ thống backend.

Latency còn ảnh hưởng đến cảm giác ổn định. Hai hệ thống cùng có thời gian trung bình 150 ms nhưng trải nghiệm có thể rất khác nếu hệ thống thứ nhất hầu hết request nằm quanh 150 ms, còn hệ thống thứ hai thường nhanh nhưng thỉnh thoảng mất vài giây. Những lần chậm bất thường này là lý do không nên đánh giá hệ thống chỉ bằng giá trị trung bình.

Với giao diện web, các tác vụ chiếm main thread từ 50 ms trở lên được Long Tasks API xem là long task và có thể làm tăng input latency, trì hoãn xử lý sự kiện hoặc gây giật khi cuộn và hoạt ảnh. Điều này cho thấy latency không chỉ phát sinh ở máy chủ hay mạng mà còn có thể xuất hiện ngay trên thiết bị của người dùng.

Nên đo độ trễ hệ thống bằng chỉ số nào?

Trước khi đọc một con số latency, cần xác định rõ điểm bắt đầu và điểm kết thúc của phép đo. RTT của mạng, thời gian xử lý database, server response time và thời gian người dùng chờ hoàn tất giao diện không đo cùng một phạm vi.

Một số phép đo thường gặp gồm:

·         One-way latency: Thời gian dữ liệu truyền theo một chiều

·         RTT (Round-Trip Time): Thời gian gửi yêu cầu tới điểm đích và nhận phản hồi trở lại

·         Server processing latency: Thời gian xử lý bên trong server sau khi nhận request

·         End-to-end latency: Toàn bộ thời gian từ phía phát sinh yêu cầu tới khi nhận được kết quả mong muốn

Khi hệ thống có lượng request lớn, percentile thường hữu ích hơn một con số trung bình duy nhất. p50 thể hiện mức latency mà 50% request hoàn thành không chậm hơn; p95 cho biết 95% request nằm dưới ngưỡng đó; p99 tập trung vào phần đuôi chậm nhất của phân phối. AWS lưu ý rằng giá trị trung bình có thể che giấu khác biệt rất lớn giữa trải nghiệm thông thường và nhóm request chậm, trong khi các percentile giúp quan sát phân phối rõ hơn.

Ví dụ, nếu p50 là 80 ms nhưng p99 là 1.200 ms, phần lớn request khá nhanh nhưng khoảng 1% request có thể chậm tới vùng trên một giây. Chỉ nhìn average hoặc p50 dễ bỏ sót vấn đề này.

Vì thế, giám sát latency nên gắn với ít nhất hai góc nhìn: trải nghiệm điển hình và tail latency. Với hệ thống quan trọng, p95 hoặc p99 thường giúp phát hiện contention, dependency chậm, cache miss hoặc các tình trạng bất thường mà giá trị trung bình không thể hiện rõ.

Những nguyên nhân nào thường làm độ trễ tăng?

Độ trễ cao thường không đến từ một nguyên nhân duy nhất. Nó có thể phát sinh ở bất kỳ mắt xích nào trên đường đi của request.

Mạng và vị trí địa lý tạo latency do khoảng cách, số hop, thiết bị trung gian, packet loss hoặc retransmission. Khi client và server ở xa nhau, không thể loại bỏ hoàn toàn độ trễ vật lý.

Tài nguyên xử lý có thể trở thành bottleneck khi CPU bận, bộ nhớ thiếu, garbage collection kéo dài hoặc số worker không đáp ứng tải. Trong trường hợp này, request dành nhiều thời gian chờ hơn trước khi được thực thi.

Cơ sở dữ liệu và lưu trữ thường làm latency tăng vì truy vấn thiếu index, lock contention, connection pool cạn, đọc ghi I/O chậm hoặc lượng dữ liệu cần quét quá lớn.

Kiến trúc phụ thuộc nhiều dịch vụ làm mỗi request phải đi qua nhiều bước. Nếu các cuộc gọi diễn ra tuần tự, latency từng bước cộng vào thời gian đầu cuối. Một dịch vụ downstream chậm cũng có thể trở thành điểm giới hạn cho toàn bộ luồng.

Cache miss, cold start và retry tạo ra latency không đồng đều. Request bình thường có thể nhanh nhưng một số request phải tải dữ liệu từ nguồn gốc, khởi tạo runtime hoặc thực hiện lại thao tác, khiến p95 và p99 tăng đáng kể.

Điểm cần phân biệt là nguyên nhân của latency không nhất thiết nằm ở thành phần có CPU cao nhất. Một hệ thống có CPU thấp vẫn có thể rất chậm nếu phần lớn thời gian request đang chờ database, network I/O, lock hoặc dịch vụ khác.

Bao nhiêu mili giây được xem là độ trễ cao?

Không tồn tại một ngưỡng latency duy nhất cho mọi hệ thống. 100 ms có thể hoàn toàn chấp nhận được đối với một tác vụ nền nhưng quá chậm đối với một vòng điều khiển thời gian thực; ngược lại, vài giây có thể vẫn phù hợp với một công việc batch dài.

Ngưỡng cần được xác định theo Information Task và SLO của dịch vụ, bao gồm loại thao tác, kỳ vọng người dùng, tải hệ thống và percentile cần bảo đảm. Google Cloud minh họa latency SLO theo dạng tỷ lệ request phải hoàn thành dưới một ngưỡng nhất định và lưu ý rằng một SLO riêng cho tail latency có thể cần thiết để nhận biết sự suy giảm ở nhóm request chậm nhất.

Các benchmark web có thể dùng làm mốc tham khảo khi đối tượng cần đánh giá là website. Ngoài INP ≤ 200 ms cho khả năng phản hồi tốt, web.dev đưa ra hướng dẫn sơ bộ rằng phần lớn website nên hướng tới TTFB ≤ 0,8 giây; TTFB trên 1,8 giây được xếp vào vùng kém. Web.dev đồng thời nhấn mạnh TTFB chỉ là hướng dẫn và không phải Core Web Vital, vì cách phân phối nội dung của từng website có thể khác nhau.

Vì vậy, không nên lấy các ngưỡng 200 ms hay 0,8 giây rồi áp trực tiếp cho database, message queue hoặc microservice. Benchmark chỉ có ý nghĩa khi phạm vi đo và loại workload tương ứng với hệ thống đang đánh giá.

Giảm độ trễ hệ thống nên bắt đầu từ đâu?

Bước đầu tiên không phải tối ưu code mà là xác định request đang mất thời gian ở đâu. Nếu chỉ có một chỉ số end-to-end, đội vận hành biết hệ thống chậm nhưng chưa biết chậm vì mạng, queue, database hay dependency.

Cách tiếp cận hiệu quả là đo theo từng đoạn của request và đối chiếu p50, p95, p99 dưới tải thực tế. Distributed tracing đặc biệt hữu ích khi một request đi qua nhiều dịch vụ vì nó cho thấy thời gian nằm ở từng span.

Sau khi xác định bottleneck, biện pháp giảm latency phải phù hợp với nguyên nhân:

·         Rút ngắn khoảng cách mạng bằng cách đặt workload hoặc dữ liệu gần người sử dụng

·         Giảm các cuộc gọi tuần tự không cần thiết, chạy song song những tác vụ thực sự độc lập

·         Dùng cache cho dữ liệu phù hợp để tránh lặp lại công việc tốn thời gian

·         Tối ưu truy vấn, index và connection pool khi thời gian tập trung ở database

·         Kiểm soát concurrency và queue để tránh thời gian chờ tăng mạnh khi hệ thống gần bão hòa

·         Thiết lập timeout, retry và backoff có kiểm soát để tránh một dependency chậm tạo thêm tải

·         Theo dõi p95, p99 và SLO thay vì chỉ nhìn average

Mục tiêu không nhất thiết là đưa mọi request về latency thấp nhất có thể. Tối ưu quá mức có thể đổi lấy chi phí hạ tầng cao, cache phức tạp hơn, dữ liệu kém nhất quán hoặc kiến trúc khó vận hành. Mục tiêu phù hợp hơn là đạt latency đủ thấp và đủ ổn định cho workload, đồng thời giữ được các yêu cầu về độ tin cậy, chi phí và khả năng mở rộng.

Độ trễ hệ thống ảnh hưởng hiệu suất vì thời gian chờ có thể xuất hiện và cộng dồn xuyên suốt mạng, hàng đợi, xử lý, cơ sở dữ liệu, dịch vụ phụ thuộc và giao diện người dùng. Khi latency tăng, response time kéo dài; dưới tải cao, hàng đợi, timeout và retry còn có thể khuếch đại vấn đề.

Đánh giá đúng độ trễ cần xác định rõ phạm vi đo, quan sát cả p50 lẫn các percentile cao như p95 hoặc p99, rồi đặt SLO phù hợp với từng workload. Một hệ thống thực sự phản hồi tốt không chỉ có latency trung bình thấp mà còn phải kiểm soát được những request chậm ở phần đuôi của phân phối.