Điểm:1

uWSGI hủy phản hồi, mất kết nối với nginx

lá cờ gb

Tôi đang chạy một ứng dụng web nhỏ được viết bằng Python, chạy bằng uWSGI và được cung cấp qua nginx. Có một thành phần tạo các tệp ZIP để tải xuống, đôi khi có thể khá lớn (vài GB). Điều thường xảy ra là kết nối giữa nginx và uWSGI bị hỏng và yêu cầu bị hủy bỏ; nginx bỏ qua phản hồi bị cắt ngắn trong khi trình duyệt hết thời gian chờ vì nó giữ cho kết nối luôn mở, mong đợi nhiều dữ liệu phản hồi hơn. Ứng dụng tạo tiêu đề Độ dài nội dung phù hợp.

Từ nhật ký uWSGI:

uwsgi_response_write_body_do(): Đường ống bị hỏng [core/writer.c dòng 429] trong khi GET [...]
OSError: ghi lỗi
SIGPIPE: ghi vào một đường ống/ổ cắm/fd đã đóng (có thể là máy khách đã ngắt kết nối) theo yêu cầu [...] !!!

tôi đã thiết lập thời gian chờ ổ cắm, socket-gửi-thời gian chờsocket-write-timeout đến 180 trong cấu hình uWSGI, không có kết quả. Conf nginx bao gồm uwsgi_read_timeout 180 giây;uwsgi_buffering tắt;

Hiệu ứng này hầu như có thể tái tạo, trong đó nó xảy ra hầu hết thời gian, đặc biệt là với các phản hồi lớn, nhưng không bao giờ ở cùng một độ lệch. Lặp đi lặp lại yêu cầu nhiều lần cuối cùng có thể dẫn đến hoàn thành.

Michael Hampton avatar
lá cờ cz
Điều này có vẻ giống sự cố thiết kế ứng dụng hơn. Các yêu cầu web thực sự không có ý định ngồi đó trong vài phút để chờ phản hồi. Thay vào đó, bạn nên bắt đầu một công việc nền để tạo tệp ZIP, sau đó cung cấp cho người dùng một URL nơi họ có thể kiểm tra trạng thái của tệp hoặc chọn tệp khi hoàn tất.
Felix avatar
lá cờ gb
@MichaelHampton Tệp được tạo nhanh chóng. Độ trễ phản hồi thường dưới 10 giây, nhưng việc gửi nội dung phản hồi cần có thời gian. Kết nối bị hủy bỏ trong khi phản hồi đã được gửi tới máy khách. Tác nhân người dùng báo cáo tiến trình tải xuống đôi khi là 20%, đôi khi là 80%, thay đổi rất nhiều, sau đó dữ liệu ngừng truyền và tại một số điểm, tác nhân người dùng báo cáo thời gian chờ trong khi tải xuống.
Michael Hampton avatar
lá cờ cz
Hừm. Bạn nên kiểm tra nhật ký lỗi nginx.
Felix avatar
lá cờ gb
Không có gì trong nhật ký lỗi nginx; nhật ký truy cập chỉ báo cáo các yêu cầu có độ dài bị cắt bớt, bỏ qua thực tế là Độ dài nội dung cho thấy rằng kết nối đã bị gián đoạn sớm.
Michael Hampton avatar
lá cờ cz
OK, vì vậy đây là một câu hỏi thú vị. Làm cách nào bạn có thể biết độ dài của tệp nén trước khi bạn nén nó?
Felix avatar
lá cờ gb
Tôi không nén các tệp vì chúng thường đã được nén sẵn (hầu hết là các tệp JPEG), vì vậy, DEFLATE sẽ không chiếm nhiều dung lượng. Các tập tin được lưu trữ mà không cần nén. Tôi nhận được một danh sách các tệp cần gửi và từ kích thước tệp của chúng, tôi tính toán chính xác dung lượng của tệp zip. Điều đó được báo cáo là Độ dài nội dung, sau đó tệp ZIP được tạo trong khi được gửi tới máy khách. Tôi đã thử nghiệm điều này rất nhiều và việc tính toán độ dài không phải là vấn đề.
Điểm:0
lá cờ gb

Hóa ra cả ứng dụng và nginx của tôi đều không phải là vấn đề, mà là bộ lọc gói bị lỗi ở phía trước cả hai.

Đă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.