Bạn đang có một phiên chạy, và một nhóm yêu cầu liên tục bị hết thời gian trong khi phần còn lại thì ổn. Kiểm tra quảng cáo thành công trong một phiên trình duyệt, thất bại trong một phiên khác, và công việc thu thập dữ liệu chỉ bỏ lỡ trang mục tiêu khi nhóm proxy thay đổi vào thời điểm không đúng. Đó là loại rắc rối mà độ trễ tạo ra, vì vấn đề thường không phải là một mẫu xấu. Đó là một phân phối ẩn sau một trung bình trông sạch sẽ.
Nếu bạn đo độ trễ theo cách sai, bạn sẽ dành hàng giờ để điều chỉnh lớp sai. Yêu cầu có thể chậm vì DNS, thiết lập TCP, đàm phán TLS, xử lý máy chủ, mất gói, hoặc chính đường đi của proxy. Trong các quy trình di động và 4G, IP công cộng, ASN, và NAT cấp nhà mạng có thể thay đổi hình dạng của những gì bạn thấy, vì vậy đường đi bạn kiểm tra trong một trung tâm dữ liệu sẽ không cho bạn biết nhiều về đường đi mà lưu lượng thực tế của bạn đi qua. Một tiêu chuẩn tốt bắt đầu bằng cách coi độ trễ như một đường cong, sau đó tách đường cong đó ra cho đến khi phần chậm rõ ràng.
Chi phí thực sự của một yêu cầu chậm
Một phiên thu thập dữ liệu trông khỏe mạnh trên giấy vẫn có thể rất mong manh trong sản xuất. Trình lập lịch công việc báo cáo thông lượng bình thường, nhưng một vài trang dừng lại đủ lâu để kích hoạt các lần thử lại, và toàn bộ lô hoàn thành muộn. Trong xác minh quảng cáo, cùng một mẫu xuất hiện như một bài kiểm tra trông ổn trong một trình duyệt tải thấp, sau đó trả về kết quả không nhất quán khi đường đi mạng thay đổi hoặc proxy thay đổi giữa phiên. Trong cả hai trường hợp, triệu chứng rõ ràng là một thời hạn bị bỏ lỡ, nhưng nguyên nhân thường trải rộng trên nhiều yêu cầu, không phải một sự cố nghiêm trọng.
Đó là lý do tại sao các giá trị trung bình là nguy hiểm. Một dịch vụ có thể có giá trị trung bình đáng kính và vẫn cảm thấy chậm với người dùng vì đuôi là xấu. Nếu bạn chỉ nhìn vào một số tóm tắt, bạn sẽ bỏ lỡ những yêu cầu chậm nhất, và đó là những yêu cầu làm hỏng quy trình đăng nhập, kiểm tra nhạy cảm về thời gian, và các bài kiểm tra phụ thuộc vào địa lý.
Quy tắc thực tiễn: coi độ trễ như một tập mẫu, không phải một lần đọc đơn lẻ. Câu hỏi đầu tiên không phải là “Giá trị trung bình là gì?” Mà là “Đuôi trông như thế nào, và điều gì đã thay đổi ở đó?”
Khi tôi gỡ lỗi một đường đi thu thập dữ liệu hoặc xác minh, tôi bắt đầu với hình dạng của độ trễ, không phải giá trị trung bình. Một giá trị trung bình sạch với p95 hoặc p99 xấu có nghĩa là hệ thống chủ yếu ổn, nhưng một phần nhỏ lưu lượng đang bị tắc nghẽn, thử lại, hoặc một bước nhảy xấu. Phần đó thường đủ để làm hỏng hành vi sản xuất.
Đối với các nhóm chạy qua các đường di động, điều này càng quan trọng hơn. Một đường 4G có thể trông ổn định trong một thời gian, sau đó thay đổi vì mạng, nhà mạng, hoặc trạng thái phiên proxy. Đó là lý do tại sao điểm tham chiếu đúng là một phân phối đầy đủ, không phải một giá trị trung bình nhỏ an tâm. Nếu bạn cần một cơ sở cho các khái niệm ổn định mạng, hãy chú ý đến bối cảnh hoạt động rộng hơn, vì độ trễ chỉ là một mặt của chất lượng đường đi: tham chiếu ổn định mạng.
Các nguyên tắc cơ bản về độ trễ bạn cần trước khi kiểm tra
Bắt đầu với các thuật ngữ quan trọng
Thời gian đi và về, RTT, là thời gian để một gói đi ra và quay lại. Đây là đơn vị cơ bản mà hầu hết các công cụ mạng cung cấp, và thường được đo bằng mili giây. Độ trễ một chiều chỉ hợp lệ khi cả hai đầu có đồng hồ được đồng bộ hóa chặt chẽ, đó là lý do tại sao hầu hết các nhóm sản xuất chỉ sử dụng RTT trừ khi họ kiểm soát thời gian ở cả hai bên. Jitter là sự biến đổi giữa các phép đo, mất gói là lưu lượng bị thiếu, và thông lượng là lượng dữ liệu mà đường đi có thể mang theo theo thời gian.
Các phần trăm cho bạn cái nhìn thực tiễn. p50 là giữa của phân phối, p95 cho thấy mức mà 95% yêu cầu nằm dưới, và p99 đi sâu hơn vào đuôi nơi những yêu cầu chậm hiếm hoi sống. Nếu giá trị trung bình ổn nhưng p95 và p99 kéo dài, người dùng của bạn vẫn sẽ cảm nhận được điều đó.
Suy nghĩ theo lớp, không phải theo một bước nhảy
Độ trễ bắt đầu từ lớp liên kết, nhưng người dùng trải nghiệm nó ở lớp ứng dụng. Một gói phải được gửi, định tuyến, vận chuyển, tái lắp ráp, và cuối cùng được xử lý bởi dịch vụ. Điều đó có nghĩa là một ping đơn lẻ chỉ có thể cho bạn một phần của câu chuyện, vì nó chủ yếu đo đường đi, không phải công việc được thực hiện bởi ứng dụng khi gói đến nơi.
Một mô hình tâm lý hữu ích là đơn giản. Chất lượng đường đi vật lý ảnh hưởng đến RTT, hành vi vận chuyển ảnh hưởng đến việc truyền lại và thiết lập kết nối, và công việc ứng dụng ảnh hưởng đến thời gian yêu cầu chờ trước khi byte đầu tiên quay lại. Đó là lý do tại sao bạn sẽ kết thúc việc đo ở nhiều lớp nếu bạn muốn có một câu trả lời đáng tin cậy.
Nếu một bài kiểm tra chỉ hiển thị một số, hãy giả định rằng nó chưa hoàn chỉnh cho đến khi được chứng minh ngược lại.
Các kết nối 4G di động thêm một lớp biến đổi khác. IP công cộng có thể nằm sau NAT cấp nhà mạng, nhiều người dùng có thể chia sẻ cùng một địa chỉ công cộng, và lưu lượng có thể được nhóm theo ngữ cảnh ASN thay vì theo một dấu chân dân cư đơn giản. Điều đó thay đổi cả hình dạng của đường đi và cách các hệ thống hạ nguồn phân loại nó, đó là lý do tại sao việc kiểm tra dựa trên proxy cần có một kỷ luật đo lường riêng.
Đo độ trễ từ dòng lệnh
Ping cho bạn RTT lần đầu
Sử dụng ping khi bạn muốn có một cái nhìn nhanh về chất lượng đường đi. Một lệnh đơn giản như ping -c 20 target cho bạn một tập mẫu nhỏ, và đầu ra thường kết thúc với min/avg/max cộng với một giá trị phân tán. Trường độ trễ để đọc là dòng RTT, không phải chuỗi gói.
Mẫu đầu ra ví dụ:
20 gói được truyền, 20 nhận, 0% mất gói
rtt min/avg/max/mdev = 12.4/18.7/41.3/6.2 ms
Ở đây, avg chỉ hữu ích như một định hướng thô, trong khi max gợi ý về đuôi. Nếu giá trị max xấu hơn nhiều so với giá trị trung bình, bạn đã học được rằng đường đi không đủ ổn định cho các quy trình nhạy cảm.
Traceroute cho thấy nơi đường đi chậm lại
Sử dụng traceroute target khi bạn cần thời gian từng bước nhảy. Số cần theo dõi là RTT được hiển thị cho mỗi bước nhảy, vì đó là nơi độ trễ tích lũy. Một bước nhảy chậm không phải lúc nào cũng có nghĩa là có lỗi, nhưng nó cho bạn biết nơi đường đi bắt đầu mở rộng.
Mẫu đầu ra ví dụ:
1 1.1 ms 1.0 ms 1.2 ms
2 4.8 ms 5.1 ms 4.9 ms
3 19.6 ms 20.1 ms 21.0 ms
Nếu bước nhảy xuất hiện ở bước 3 và vẫn cao sau đó, nút thắt có thể nằm ở phía trên của mục tiêu, không phải bên trong nó. Nếu bước nhảy chậm đầu tiên xuất hiện và các bước nhảy sau phục hồi, đừng giải thích quá mức. Một số bộ định tuyến giảm ưu tiên các phản hồi thăm dò, điều này khiến chúng trông chậm mà không làm hại lưu lượng thực tế.
MTR kết hợp hai cái nhìn
mtr target hữu ích khi bạn muốn có báo cáo trực tiếp về cả đường đi và mất mát. Các cột cần đọc là Mất% và Trung bình. Một bước nhảy với mất mát tăng và RTT trung bình tăng đáng lo ngại hơn một bước nhảy với một đỉnh kỳ lạ đơn lẻ.
Mẫu đầu ra ví dụ:
Host Mất% Trung bình Tốt nhất Tệ nhất
1 0.0% 1.1 1.0 1.5
2 0.0% 5.0 4.8 5.4
3 2.0% 20.4 19.7 41.2
Lệnh này hữu ích nhất khi bạn để nó chạy đủ lâu để thấy các mẫu thay vì các đỉnh đơn lẻ. Đối với công việc proxy, điều đó quan trọng vì một lộ trình đã thay đổi có thể trông ổn trong một phút và sau đó trôi dạt khi phiên thay đổi. Nếu bạn đang xây dựng một tiêu chuẩn lặp lại xung quanh tốc độ proxy, hãy giữ phiên ổn định và so sánh phiên chạy với một cơ sở cố định, sau đó sử dụng một quy trình kiểm tra tốc độ proxy chuyên dụng như hướng dẫn kiểm tra tốc độ proxy này.
Iperf3 cho bạn biết cách liên kết hoạt động dưới tải
Sử dụng iperf3 khi bạn quan tâm đến khả năng và độ nhạy với tải. Một lệnh cơ bản như iperf3 -c target kiểm tra cách đường đi hoạt động khi dữ liệu đang chảy, không chỉ khi một thăm dò đang quay lại. Trường cần theo dõi là tốc độ truyền, vì độ trễ thường xấu đi khi liên kết trở nên bận rộn.
Mẫu đầu ra ví dụ:
[ ID] Khoảng thời gian Chuyển giao Tốc độ
[ 5] 0.00-10.00 giây 120 MBytes 101 Mbits/giây
Đó không phải là một con số độ trễ tự nó, nhưng nó cho bạn biết liệu sự tắc nghẽn có thể ảnh hưởng đến thời gian yêu cầu của bạn hay không. Nếu thông lượng sụp đổ dưới tải, đường đi của yêu cầu sẽ cảm thấy áp lực ở đâu đó.
Tcpdump và tshark phơi bày thời gian cấp gói
tcpdump dùng để ghi lại, và tshark hoặc Wireshark dùng để phân tích. Ghi lại luồng, sau đó kiểm tra thống kê ICMP hoặc vận chuyển để xem tối thiểu, tối đa, trung bình, trung vị và độ lệch chuẩn. Những trường đó giúp bạn hiểu liệu phân phối có chặt chẽ hay ồn ào.
Mẫu ghi lại ví dụ:
tcpdump -i any host target
Thống kê ICMP: tối thiểu 12 ms, tối đa 71 ms, trung bình 19 ms, trung vị 16 ms, độ lệch chuẩn 8 ms
Đó là cái nhìn trung thực nhất bạn sẽ nhận được khi một ping trung bình che giấu hình dạng của đuôi. Nó cũng hữu ích khi bạn nghi ngờ rằng bước nhảy proxy đang thêm độ trễ theo cách mà công cụ từng bước không thể giải thích rõ ràng.
Độ trễ Ứng dụng và Trình duyệt Bạn Có Thể Thấy Thực Tế
Một yêu cầu có thể trông nhanh ở lớp mạng nhưng vẫn cảm thấy chậm trong trình duyệt. Đó là lý do tại sao tôi luôn phân tích nó với curl trước khi tin tưởng bất kỳ điều gì khác. Các trường hữu ích là thời gian DNS, thời gian kết nối TCP, thời gian TLS, TTFB cho thời gian đến byte đầu tiên, và thời gian tổng cộng.
Một lệnh thực tiễn trông như thế này:
curl -o /dev/null -s -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com
Đầu ra mẫu:
dns:0.012 tcp:0.045 tls:0.089 ttfb:0.150 total:0.320
Dòng đó cho bạn biết nơi chờ đợi đang diễn ra. Nếu DNS rẻ nhưng TTFB chậm, thì máy chủ hoặc đường đi proxy là vấn đề. Nếu TCP và TLS là nguyên nhân kéo, bạn đang nhìn vào thiết lập kết nối, không phải truyền tải nội dung.
Sử dụng thác nước trình duyệt cho thời gian người dùng
Công cụ phát triển trình duyệt cung cấp cho bạn một góc nhìn khác. Thác nước trong bảng Mạng cho thấy mỗi yêu cầu đã tiêu tốn thời gian ở đâu, và tab Thời gian chia nó thành tạm dừng, tra cứu DNS, kết nối ban đầu, SSL, yêu cầu đã gửi, chờ đợi (TTFB), và tải nội dung. Sự phân chia đó quan trọng vì một trang có thể xuất hiện bị hỏng ngay cả khi backend đang hoạt động tốt.
Nếu thác nước cho thấy hầu hết thời gian chờ trước khi yêu cầu được gửi đi, thì trình duyệt hoặc đường đi proxy là điểm nghẽn. Nếu chờ đợi chiếm ưu thế, backend chậm phản hồi. Nếu tải nội dung là yếu tố kéo dài, thì tải trọng quá nặng hoặc kết nối quá hạn chế.
Thói quen hữu ích: so sánh thác nước trình duyệt với dòng thời gian
curltừ cùng một mục tiêu. Nếu chúng không đồng ý, đường đi trình duyệt có thêm chi phí mà bài kiểm tra CLI của bạn không thấy.
Giám sát tổng hợp và giám sát người dùng thực tế phục vụ các mục đích khác nhau. Các kiểm tra tổng hợp được kiểm soát và có thể lặp lại, điều mà bạn muốn cho kiểm tra hồi quy. Thời gian người dùng thực tế ghi lại những gì khách truy cập thực sự trải nghiệm, điều này tốt hơn để phát hiện các vấn đề dài hạn chỉ xuất hiện trong thực tế.
Đối với công việc trong pipeline, câu trả lời sạch nhất thường là ghi thời gian sự kiện tại nhập, xử lý, và phục vụ, sau đó trừ các điểm liền kề. Khung theo giai đoạn của Amplitude cho thời gian sự kiện và định nghĩa độ trễ dữ liệu của Snowplow đều chỉ ra cùng một ý tưởng, con số hữu ích thường là thời gian từ giai đoạn này sang giai đoạn khác, không chỉ là tổng thời gian từ đầu đến cuối. Đó là hồ sơ độ trễ mà xác minh quảng cáo và quy trình nghiên cứu thị trường thường cần.
Đọc Các Con Số Mà Không Lừa Dối Bản Thân
Một trung bình có thể trông khỏe mạnh trong khi trải nghiệm người dùng lại tồi tệ. Giả sử hầu hết các yêu cầu hoàn thành trong một dải nhỏ, nhưng một vài yêu cầu chậm kéo dài ra xa. Trung vị có thể giữ bình tĩnh, trung bình có thể chỉ di chuyển một chút, và tuy nhiên những người bị ảnh hưởng bởi đuôi cảm thấy hệ thống bị hỏng.
Đọc các phần trăm như một hình dạng
p50 cho bạn biết cảm giác bình thường như thế nào. p95 cho bạn biết đuôi phổ biến kéo dài bao xa. p99 cho bạn biết liệu cơn đau hiếm có đang len lỏi vào sản xuất hay không. Khi p50 giữ phẳng nhưng p99 tăng lên, hệ thống trở nên ít dự đoán hơn ngay cả khi trung tâm của phân phối trông ổn.
Đó là nơi đầu tiên tôi nhìn vào một bài kiểm tra chuẩn sản xuất. Nếu p99 xấu, tôi ngừng coi trung bình là một chỉ số quyết định và bắt đầu coi nó như một nguồn tiếng ồn.
Phân tách vấn đề nhảy khỏi vấn đề dịch vụ
Một bước nhảy đầu tiên chậm trong traceroute hoặc MTR thường chỉ ra sự tắc nghẽn đường đi, khoảng cách, hoặc chính đường đi proxy. Một bước nhảy mất gói có thể là một hiện tượng định tuyến, đặc biệt nếu các bước nhảy sau không suy giảm theo cách tương tự. Một tra cứu DNS chậm có nghĩa là bạn nên kiểm tra việc phân giải tên một cách riêng biệt, trong khi một bắt tay TLS chậm thường có nghĩa là thiết lập kết nối hoặc thương lượng chứng chỉ là nguyên nhân kéo. Nếu phía máy chủ chậm sau tất cả những điều đó, thời gian đến byte đầu tiên sẽ cho thấy điều đó.
Quy trình làm việc an toàn nhất là lặp lại, không phải thông minh. Thiết lập một cơ sở, kiểm tra dưới tải, phân chia theo thời gian trong ngày và theo ngày trong tuần so với cuối tuần, sau đó tìm kiếm mất gói và các bước nhảy chậm. Một bức tranh có thể nói dối, nhưng mẫu theo thời gian thường không.
Đối với xác minh quảng cáo và thu thập dữ liệu, công việc bắt đầu từ đây. Một con đường chấp nhận được trong giờ thấp điểm có thể trở nên không ổn định khi nhà mạng hoặc đường đi phía trên thay đổi. Nếu đường đi thay đổi giữa các bài kiểm tra, các phần trăm của bạn ngừng mô tả một hệ thống và bắt đầu mô tả một số hệ thống khác nhau.
Đo Độ Trễ Qua Các Proxy Di Động và 4G
Một yêu cầu có thể trông nhanh từ một trung tâm dữ liệu nhưng vẫn cảm thấy chậm khi rời khỏi mạng di động. ASN thay đổi bức tranh trước khi gói đến mục tiêu của bạn, vì nó cho thấy mạng nào sở hữu địa chỉ và đường đi phía trên mà bạn thực sự đang kiểm tra. NAT cấp nhà mạng lại thay đổi nó, vì một địa chỉ IP công cộng chia sẻ có thể ẩn đi sự cạnh tranh thêm và làm cho cùng một yêu cầu hành xử khác nhau từ lần chạy này sang lần chạy khác.
Đó là lý do tại sao bài kiểm tra phải giữ cố định trên một đường đi. Nếu bạn xoay vòng địa chỉ IP proxy trong khi thu thập mẫu, bạn ngừng đo lường một kết nối duy nhất và bắt đầu hòa trộn một số đường đi thành một tập hợp các phần trăm. Giữ phiên ổn định giống nhau trong suốt quá trình chạy, sau đó lặp lại bài kiểm tra sau khi xoay vòng nếu bạn muốn thấy đường đi thay đổi bao nhiêu. Để có ghi chú thiết lập sâu hơn về định tuyến di động, hướng dẫn proxy 4G LTE này là nơi rõ ràng nhất để kiểm tra hành vi phiên mà bạn cần giữ ổn định.
Những gì cần giữ cố định trong suốt bài kiểm tra
- Giữ phiên ổn định: Không xoay vòng địa chỉ IP trong khi bạn thu thập mẫu độ trễ. Một thay đổi trong đường đi có thể làm thay đổi phân phối đủ để làm cho bài kiểm tra chuẩn khó đọc.
- Kiểm tra ASN trước: Xác nhận xem đường đi nằm trong mạng di động, đường đi dân cư, hay đường đi trung tâm dữ liệu trước khi bạn so sánh kết quả.
- Sử dụng cùng một điểm cuối và cùng một khoảng thời gian: Nếu không, bạn sẽ trộn lẫn các thay đổi mạng với các thay đổi khối lượng công việc, và kết quả sẽ không còn hữu ích.
- So sánh giống với giống: Chạy cùng một yêu cầu từ nguồn gốc, sau đó qua một proxy dân cư, sau đó qua một proxy di động 4G.
So sánh cuối cùng đó là cái gần nhất với hành vi sản xuất. Một đường đi di động với một phiên ổn định cho bạn cái nhìn rõ ràng hơn về những gì xác minh quảng cáo hoặc lưu lượng thu thập dữ liệu sẽ thấy, trong khi một phiên xoay vòng cho bạn biết nhiều hơn về sự thay đổi hơn là độ trễ.
Tại sao traceroute có thể trông lạ trên 4G
Một đường đi 4G hiếm khi trông giống như một đường đi doanh nghiệp sạch sẽ. Một số bước nhảy không bao giờ trả lời, một số phản hồi bị giới hạn theo tỷ lệ, và địa chỉ IP công cộng có thể nằm sau một cạnh nhà mạng thay vì một máy đơn lẻ. Traceroute vẫn hữu ích, nhưng hãy coi nó như một cách để đọc hình dạng của đường đi, không phải như một bản đồ hoàn hảo của mọi bước nhảy.
Thói quen hoạt động giữ vững là đơn giản. Kiểm tra ba đường đi bên cạnh nhau, mạng gốc của bạn, cùng một yêu cầu qua một proxy dân cư, sau đó cùng một yêu cầu qua một proxy di động 4G. Giữ phiên cố định trong mỗi trường hợp, sau đó so sánh p50, p95, p99, và tối đa. Điều đó cho bạn một cái nhìn thực tiễn về độ trễ trước khi lưu lượng sản xuất xảy ra.
Các Cạm Bẫy Thường Gặp và Danh Sách Kiểm Tra Bạn Có Thể Tái Sử Dụng
- Chỉ kiểm tra trên các mạng nhàn rỗi. Các con số có thể trông sạch sẽ trên một đường dẫn yên tĩnh và sẽ sụp đổ khi lưu lượng thực tế chia sẻ liên kết. Vấn đề không phải là bài kiểm tra, mà là trạng thái mạng trong quá trình kiểm tra. Sửa: lặp lại bài kiểm tra trong các khoảng thời gian bận rộn và so sánh sự thay đổi trong phân phối.
- Lấy một cửa sổ mẫu duy nhất. Một lần chạy ngắn có thể trông kết luận trong khi vẫn khó lặp lại. Vấn đề là tiếng ồn về thời gian và một đường dẫn đã thay đổi dưới bạn. Sửa: thu thập nhiều cửa sổ và so sánh sự phân tán, không chỉ số liệu chính.
- Bỏ qua độ trễ đuôi. Một trung bình khỏe mạnh có thể che giấu các yêu cầu chậm mà người dùng cảm nhận. Vấn đề xuất hiện ở cuối phân phối, không phải ở giữa. Sửa: đọc p95, p99 và max cùng nhau, sau đó quyết định xem độ trễ có chấp nhận được không.
- Thay đổi proxy giữa chừng kiểm tra. Nếu phiên thay đổi giữa chừng, lộ trình cũng thay đổi theo và các phần trăm không còn có ý nghĩa nhiều. Điều này thường xảy ra trên các đường dẫn di động với NAT cấp nhà mạng và hành vi phiên dính, nơi một lần chạy có thể ở lại một điểm ra và lần tiếp theo có thể không. Sửa: giữ một phiên dính cho toàn bộ lần chạy.
- Chỉ đo lường máy chủ. Một tìm kiếm DNS chậm hoặc một quá trình bắt tay TLS bị trì hoãn có thể bị đổ lỗi cho backend ngay cả khi ứng dụng không phải là nút thắt cổ chai. Bộ đếm thời gian phải phân tách thiết lập kết nối, thời gian bắt tay và thời gian phản hồi. Sửa: chia yêu cầu thành các giai đoạn đó và ghi lại từng giai đoạn.
- Sử dụng trung bình để báo cáo. Một trung bình có thể làm phẳng trải nghiệm người dùng kém thành một con số trông vô hại. Điều đó che giấu các yêu cầu không thành công trong việc thu thập dữ liệu, kiểm tra xác thực quảng cáo, hoặc quy trình QA di động. Sửa: báo cáo các phần trăm phù hợp với các yêu cầu thực tế và giữ max thô trong tầm nhìn.
- Tắt trước khi các yêu cầu đang xử lý hoàn thành. Một lần chạy kết thúc quá sớm có thể bỏ lỡ các yêu cầu chậm nhất và làm cho tiêu chuẩn trông tốt hơn thực tế. Cửa sổ thu thập không đầy đủ, vì vậy max bị đánh giá thấp. Sửa: để tiêu chuẩn xả hết trước khi bạn dừng nó.
Đối với proxy di động và quy trình làm việc 4G, danh sách kiểm tra rất đơn giản. Xác nhận ASN và hành vi phiên trước khi bạn so sánh kết quả, giữ điểm cuối và cửa sổ thời gian ổn định, thu thập đủ mẫu để thấy độ trễ, và xác minh rằng các điều kỳ lạ của traceroute là điều mong đợi cho đường dẫn nhà mạng mà bạn đang sử dụng. Nếu bạn cần một tài liệu tham khảo cho hành vi proxy 4G và LTE, hãy sử dụng trang wiki mà bạn đã giữ cho thiết lập đó, sau đó kiểm tra so với cơ sở của riêng bạn thay vì giả định một đường dẫn sẽ hoạt động giống như đường dẫn khác.
