Điểm:2

Điều gì có thể gây ra độ trễ/độ trễ của yêu cầu TCP/HTTP

lá cờ in

Chúng tôi có một thiết bị gửi các yêu cầu POST hoặc tin nhắn TCP trong các khoảng thời gian cố định, với tải trọng JSON, qua internet tới máy chủ của chúng tôi đang chạy ứng dụng nút, ở một vị trí khác.

Tải trọng JSON có dấu thời gian và một số giá trị khác.Chúng tôi so sánh dấu thời gian đó với dấu thời gian của máy chủ để tính chênh lệch thời gian mà chúng tôi gọi là độ trễ.

Khoảng thời gian là 100ms. Những gì chúng tôi trải nghiệm là ban đầu, độ trễ dưới 200 mili giây. Chúng tôi để hệ thống chạy trong vài ngày và chúng tôi quan sát thấy độ trễ ngày càng tăng, sau 2-3 ngày là 2000 - 3000ms và tăng thêm .. sau 6 ngày khoảng 6000ms.

Sau khi chúng tôi khởi động lại quá trình máy chủ, độ trễ sẽ trở lại bình thường, vì vậy tôi cho rằng người gửi vẫn ổn. Điều này xảy ra với cả hai, triển khai yêu cầu POST và triển khai thông báo TCP.

Có ai biết tại sao điều này có thể xảy ra hoặc làm thế nào để thu hẹp vấn đề không?

lá cờ sh
Ben
Vì AlexD chỉ ra rằng đồng hồ của máy chủ và máy khách có thể khác nhau. Để kiểm tra thời gian, tốt nhất là lấy thời gian bắt đầu/kết thúc trên cùng một máy.
lá cờ jp
Bạn có thể thử kích hoạt/thời gian gửi tin nhắn theo cách thủ công vào ngày 1 so với ngày 3 và so sánh hiệu suất không? Bạn sẽ chạy nó theo cách thủ công, vì vậy bạn muốn bỏ qua dấu thời gian/đăng nhập để xem hiệu suất một cách trực quan. Điều này sẽ giúp thu hẹp xem sự cố có phải do đồng bộ hóa hay không (nếu chạy thủ công nhanh) so với độ trễ thực tế (nếu chạy thủ công chậm)?
VL-80 avatar
lá cờ cn
Nếu có thể, hãy thiết lập cặp thiết bị-máy chủ thử nghiệm trong môi trường được kiểm soát, gần nhau và xem sự cố có tiếp diễn hay không. Nó sẽ cho phép bạn loại bỏ khía cạnh mạng của vấn đề và sẽ giúp thu hẹp vấn đề nếu bạn nghi ngờ rằng việc định tuyến qua Internet góp phần gây ra sự cố.
Ben Voigt avatar
lá cờ pl
Bạn cũng nên đo thời gian khứ hồi, vì điều này cần hai phép đo từ một nguồn đồng hồ duy nhất, không thể nhầm lẫn bất kỳ sự không khớp/lỗi/độ lệch đồng hồ nào với độ trễ/độ trễ.
lá cờ in
Máy khách là một thiết bị có hệ điều hành riêng. Tôi đã cố gắng mô phỏng thiết bị nhưng không thể tái tạo sự cố. Thời gian khứ hồi khá thấp, thường dưới 20 mili giây. Sin sinh sản mất nhiều ngày, quá trình tìm kiếm này là tương đối chậm.
Điểm:6
lá cờ jp

Bạn có đồng bộ hóa đồng hồ trên cả máy chủ và người gửi không? 1 giây mỗi ngày không phải là độ lệch đồng hồ bất thường.

lá cờ cn
`Sau khi chúng tôi khởi động lại quá trình máy chủ, độ trễ sẽ trở lại bình thường` gợi ý ngược lại.
lá cờ jp
@rtaft có thể họ đang sử dụng một số đồng hồ không chính xác (`setInterval`?) Trong quy trình dịch vụ của họ sẽ trôi theo thời gian. Hoặc họ đang khởi động lại quá trình bằng cách khởi động lại máy chủ chạy `ntpdate` khi khởi động nhưng không chạy dịch vụ `ntpd`.
lá cờ jp
@AlexD: Không nên do khoảng thời gian không chính xác, vì họ đang gửi dấu thời gian của máy chủ trong tải trọng. Trôi theo khoảng thời gian cũng sẽ làm trôi dấu thời gian đi kèm. Tuy nhiên, trôi đồng hồ là một khả năng rất thực tế, đặc biệt nếu OP đang sử dụng máy chủ ảo/đám mây thay vì máy chuyên dụng.
lá cờ jp
@Brian, chúng tôi không biết cách họ tính dấu thời gian của họ. Họ có thể lấy thời gian hệ thống một lần khi bắt đầu và sau đó thêm các khoảng thời gian.
lá cờ in
Chúng tôi lấy ngày qua javascript `new Date()` trên máy chủ. Đồng hồ trôi là không thể, nhưng tôi sẽ ghi nhớ nó.
Điểm:3
lá cờ cn

Điều này sẽ chỉ ra những gì được gọi là rò rỉ tài nguyên. Thứ gì đó trong ứng dụng của bạn đang làm chậm quá trình xử lý theo thời gian do hàng đợi hoặc bộ nhớ hoặc một số tài nguyên khác tích tụ.

Tôi khuyên bạn nên thêm công cụ vào mã NodeJS của mình để theo dõi bất kỳ hàng đợi nội bộ nào, cấp phát bộ nhớ, tra cứu cơ sở dữ liệu, v.v. Ghi nhật ký tất cả mọi thứ để bạn có thể bắt đầu xác định vị trí nút thắt cổ chai.

Nếu bạn đang chạy trên đám mây, có những công cụ tốt để trợ giúp mã công cụ, chẳng hạn như AWS X-Ray.

lá cờ in
Cảm ơn. Tôi sẽ kiểm tra lại mã của mình.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.