bị trì hoãn trong một thời gian dài thỉnh thoảng trong chrome

Question

Yêu cầu Ajax đôi khi bị trì hoãn trong một thời gian dài trong chrome.

Cuối cùng tôi đã quản lý để sao chép và lưu tất cả dữ liệu có liên quan cần thiết để đăng ở đây nếu có ai đó có thể giúp tôi.

Các mốc thời gian từ Chrome Công cụ Dev cho thấy yêu cầu bị đình trệ cho 42.62s như chụp màn hình dưới đây cho thấy:

và trong chrome://net-internals/#events (đối với các sự kiện đăng nhập xin vui lòng đi đến kết thúc) trang tôi thấy nhiều nhất Hiện đang có giá bằng hai sự kiện:

• + HTTP_TRANSACTION_READ_HEADERS [dt = 21.301]
• + HTTP_TRANSACTION_READ_HEADERS [dt = 21.304]

cả hai đều nhận được ERR_CONNECTION_RESET.

Tôi nghĩ rằng lỗi là lý do tại sao các yêu cầu trì hoãn quá lâu.

Bất kỳ ai có thể giải thích lỗi?

SAU LÀ SỰ KIỆN ĐĂNG NHẬP ĐỐI VỚI YÊU CẦU, Tôi cũng xuất toàn bộ sự kiện dưới dạng json bạn có thể nhận được từ here rồi khôi phục trong trang chrome://net-internals/#events của Chrome. lưu ý địa chỉ yêu cầu là nội bộ truy cập như vậy có lẽ không thể từ mạng công cộng:

193486: URL_REQUEST 
 
http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593 
 
Start Time: 2015-01-02 17:51:05.323 
 

 
t= 1 [st= 0] +REQUEST_ALIVE [dt=42741] 
 
t= 1 [st= 0] URL_REQUEST_DELEGATE [dt=0] 
 
t= 1 [st= 0] +URL_REQUEST_START_JOB [dt=42740] 
 
         --> load_flags = 339804160 (BYPASS_DATA_REDUCTION_PROXY | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT) 
 
         --> method = "GET" 
 
         --> priority = "LOW" 
 
         --> url = "http://qa.tieba.baidu.com/release/getReleaseHistory?projectId=fum1.0.593" 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_GET_BACKEND [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_OPEN_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_ADD_TO_ENTRY [dt=0] 
 
t= 2 [st= 1]  HTTP_CACHE_READ_INFO [dt=0] 
 
t= 2 [st= 1]  URL_REQUEST_DELEGATE [dt=0] 
 
t= 2 [st= 1]  +HTTP_STREAM_REQUEST [dt=2] 
 
t= 4 [st= 3]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193488 (HTTP_STREAM_JOB) 
 
t= 4 [st= 3]  -HTTP_STREAM_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_SEND_REQUEST [dt=0] 
 
t= 4 [st= 3]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t= 4 [st= 3]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t= 4 [st= 3]  +HTTP_TRANSACTION_READ_HEADERS [dt=21301] 
 
t= 4 [st= 3]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21301] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=21305 [st=21304]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=21305 [st=21304]  +HTTP_STREAM_REQUEST [dt=3] 
 
t=21307 [st=21306]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193494 (HTTP_STREAM_JOB) 
 
t=21308 [st=21307]  -HTTP_STREAM_REQUEST 
 
t=21308 [st=21307]  +HTTP_TRANSACTION_SEND_REQUEST [dt=3] 
 
t=21308 [st=21307]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=21311 [st=21310]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=21311 [st=21310]  +HTTP_TRANSACTION_READ_HEADERS [dt=21304] 
 
t=21311 [st=21310]  HTTP_STREAM_PARSER_READ_HEADERS [dt=21304] 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  HTTP_TRANSACTION_RESTART_AFTER_ERROR 
 
          --> net_error = -101 (ERR_CONNECTION_RESET) 
 
t=42615 [st=42614]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42615 [st=42614]  +HTTP_STREAM_REQUEST [dt=12] 
 
t=42627 [st=42626]  HTTP_STREAM_REQUEST_BOUND_TO_JOB 
 
          --> source_dependency = 193498 (HTTP_STREAM_JOB) 
 
t=42627 [st=42626]  -HTTP_STREAM_REQUEST 
 
t=42627 [st=42626]  +HTTP_TRANSACTION_SEND_REQUEST [dt=2] 
 
t=42627 [st=42626]  HTTP_TRANSACTION_SEND_REQUEST_HEADERS 
 
          --> GET /release/getReleaseHistory?projectId=fum1.0.593 HTTP/1.1 
 
           Host: qa.tieba.baidu.com 
 
           Connection: keep-alive 
 
           Accept: application/json, text/plain, */* 
 
           User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 
 
           Referer: http://qa.tieba.baidu.com/project/ 
 
           Accept-Encoding: gzip, deflate, sdch 
 
           Accept-Language: en-US,en;q=0.8 
 
           Cookie: [268 bytes were stripped] 
 
t=42629 [st=42628]  -HTTP_TRANSACTION_SEND_REQUEST 
 
t=42629 [st=42628]  +HTTP_TRANSACTION_READ_HEADERS [dt=112] 
 
t=42629 [st=42628]  HTTP_STREAM_PARSER_READ_HEADERS [dt=112] 
 
t=42741 [st=42740]  HTTP_TRANSACTION_READ_RESPONSE_HEADERS 
 
          --> HTTP/1.1 200 OK 
 
           Date: Fri, 02 Jan 2015 09:51:48 GMT 
 
           Content-Type: application/json; charset=UTF-8 
 
           Transfer-Encoding: chunked 
 
           Connection: keep-alive 
 
           Cache-Control: no-cache 
 
           tracecode: 31079600320335034634010217 
 
           tracecode: 31079600320537995786010217 
 
           Server: Apache 
 
t=42741 [st=42740]  -HTTP_TRANSACTION_READ_HEADERS 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740]  HTTP_CACHE_WRITE_INFO [dt=0] 
 
t=42741 [st=42740]  URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] -URL_REQUEST_START_JOB 
 
t=42741 [st=42740] URL_REQUEST_DELEGATE [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42741 [st=42740] HTTP_TRANSACTION_READ_BODY [dt=0] 
 
t=42741 [st=42740] HTTP_CACHE_WRITE_DATA [dt=0] 
 
t=42742 [st=42741] -REQUEST_ALIVE

EDIT: Vấn đề liên quanIssue 447463: Chrome-network: Long delay before RST message on stale sockets results in slow page loads.

Answer 1

Tôi đã từng gặp phải một vấn đề tương tự. Nguyên nhân của vấn đề là mọi trình duyệt đều có giới hạn số lượng kết nối TCP tối đa đến một máy chủ. Đối với chrome, giới hạn là sáu. Vấn đề là nổi bật hơn khi bạn đang sử dụng một máy chủ proxy, bởi vì tất cả các yêu cầu đi cùng một máy chủ (máy chủ proxy).

Chrome không cho phép bạn thay đổi giới hạn này. Nó không phải trong thực tế. Nếu bạn muốn biết thêm về lý do tại sao giới hạn này tồn tại và giới hạn cho các trình duyệt khác là gì, bạn có thể đọc this article.

Lý do tại sao giới hạn này hiếm khi là một vấn đề là do nhiều yêu cầu HTTP đến cùng một máy chủ chủ yếu được gửi liên tiếp, thay vì song song, tốt nhất là trên cùng kết nối TCP.

Nếu vấn đề này xảy ra với bạn thường xuyên, thì lý do có thể là:

1. Server không hỗ trợ kết nối TCP dai dẳng: Nếu vấn đề chỉ khi truy cập vào một máy chủ cụ thể, các lý do có thể xảy ra là chrome đang tìm nạp nhiều tài nguyên (như hình ảnh, tệp CSS, v.v) trên các kết nối song song. Vì, trong trường hợp của bạn, máy chủ nằm trong mạng cục bộ của bạn, bạn có thể yêu cầu quản trị viên của máy chủ thêm hỗ trợ cho các kết nối TCP liên tục.

2. Nhiều kết nối liên tục được mở: Nếu bạn đang làm việc phía sau một máy chủ proxy, sau đó tải về nhiều file cùng một lúc hoặc mở các trang web mà giữ một kết nối TCP mở có thể là nguyên nhân của problem.To bạn thoát khỏi nó, tất cả những gì bạn có thể làm là không tải xuống nhiều thứ cùng một lúc (hoặc tải xuống trong một trình duyệt khác, nếu bạn phải).

PS: Các lỗi net_error = -101 (ERR_CONNECTION_RESET) là không phải do tiêu đề không hợp lệ, đó là vì thời gian chờ, chờ đợi đối với một số kết nối đến máy chủ trước để đóng.

Answer 2

Vấn đề tương tự ở đây và có vẻ như sau một khoảng thời gian, khoảng 3 phút ổ cắm chrome đang cố gắng sử dụng được đóng (tôi giả định) bởi hệ điều hành.

Điều này cũng được liệt kê dưới dạng lỗi trong diễn đàn Chromium. Tôi đoán thiếu một số loại cơ chế "tiếp tục sống" .: https://code.google.com/p/chromium/issues/detail?id=447463

Thông báo lỗi của tôi hơi khác nhưng có thể do ứng dụng của tôi thực hiện cuộc gọi qua SSL. Dưới đây là những gì tôi nhìn thấy trong chrome: // net-internals:

chrome đầu tiên tìm thấy một ổ cắm hiện có và yêu cầu được liên kết với nó (HTTP_STREAM_JOB):

t=1572 [st=0] HTTP2_SESSION_POOL_FOUND_EXISTING_SESSION 
        --> source_dependency = 1347215 (HTTP2_SESSION) 
    t=1572 [st=0] HTTP_STREAM_JOB_BOUND_TO_REQUEST 
        --> source_dependency = 1348612 (URL_REQUEST) 
    t=1572 [st=0] -HTTP_STREAM_JOB 

Sau đó trở lại trong (URL_REQUEST) bạn sẽ thấy nó thời gian ra, lưu ý 10 giây trôi đi trong thời gian từ t = 1572 t = 11.573:

t= 1572 [st= 0] HTTP2_SESSION_SEND_DATA 
         --> fin = true 
         --> size = 48 
         --> stream_id = 3 
    t= 1572 [st= 0] HTTP2_SESSION_UPDATE_SEND_WINDOW 
         --> delta = -48 
         --> window_size = 2147483551 
    t=11573 [st=10001] HTTP2_SESSION_CLOSE 
         --> description = "Failed ping." 
         --> net_error = -352 (ERR_SPDY_PING_FAILED) 

rõ ràng có một thời gian chờ khi chrome cố gắng để điều chỉnh kích thước cửa sổ trên ổ cắm hiện có. Tôi cho rằng điều này là do không hoạt động trên socket.

Tôi sẽ cố gắng thực hiện một số loại yêu cầu nhịp tim tại khoảng thời gian có lẽ 60 giây để xem sự cố vẫn còn. Tôi sẽ đăng một bản cập nhật với kết quả.

CẬP NHẬT:

Nhập mã sau vào javascript được tải trên mỗi trang. Này được lấy một doc html trống từ gốc công cộng:

$(document).ready(function() { 
     $.keepalive =  
       setInterval(function() { 
        $.ajax({ 
         url: '/ping.html', 
         cache: false 
        });   
       }, 60000);  
    }); 

Điều này dường như đã giúp giữ cho ổ cắm mở ngay cả với những mẫu dưới đây cho thấy khoảng 6 phút giữa "thật" kêu gọi:

Tại 570B cho mỗi cuộc gọi trong khoảng 60 giây, cuộc gọi ping sẽ thêm khoảng 800kb sử dụng băng thông mỗi 24 giờ (mỗi phiên trình duyệt). Tôi không chắc chắn bao nhiêu CPU trên máy chủ này sẽ gây ra.

Để so sánh, các TRƯỚC:

Cần phải có một giải pháp tốt hơn, nhưng tôi đã không thể xác định vị trí một được nêu ra.