Giải thích HTTP 504 Gateway Timeout

Scrapeless Web Unlocker truy xuất nội dung trang công khai cho các quy trình làm việc cần phân biệt thời gian chờ thượng nguồn với dữ liệu nguồn đã được chấp nhận.

HTTP 504 Gateway Timeout có nghĩa là một máy chủ đóng vai trò gateway hoặc proxy đã không nhận được phản hồi kịp thời từ một máy chủ thượng nguồn cần thiết để hoàn tất yêu cầu. Đồng hồ của gateway đã hết giờ, nhưng công việc chậm có thể nằm sâu hơn trong đường đi của yêu cầu. Hãy tìm xem thời gian đã được tiêu tốn ở đâu trước khi nâng bất kỳ thời hạn nào.

Gateway Timeout chứng minh điều gì

Gateway timeout chứng minh rằng một trung gian đã không nhận được phản hồi thượng nguồn mà nó cần trong khoảng thời gian chờ áp dụng cho nó. Định nghĩa ngữ nghĩa HTTP của 504 mô tả ranh giới này. Mã trạng thái không cho biết liệu máy chủ thượng nguồn không thể truy cập, đang bận, đang chờ một phụ thuộc khác, hay đang thực hiện một công việc tốn kém bất thường.

Gateway có thể đã chấp nhận kết nối của client một cách bình thường. Sau đó nó có thể sử dụng hết toàn bộ ngân sách thượng nguồn của mình để chờ trước khi trả về tài liệu lỗi 504. Client nhận được một phản hồi HTTP hoàn chỉnh, mặc dù thao tác được yêu cầu đã không trả về kết quả mong đợi qua đường dẫn đó.

Xác định gateway đã phát ra mã trạng thái. Một yêu cầu có thể đi qua CDN, bộ cân bằng tải, reverse proxy, cổng ứng dụng và service mesh nội bộ. Một thành phần bên ngoài có thể chuyển tiếp 504 bên trong hoặc tự tạo ra mã này. Nhật ký và truy vết là cần thiết để xác định bộ đếm thời gian nào đã kết thúc yêu cầu mà người dùng quan sát.

Dựng lại dòng thời gian phía thượng nguồn

Dòng thời gian thượng nguồn nên tính đến việc thiết lập kết nối, xếp hàng, công việc ứng dụng, các cuộc gọi phụ thuộc và việc gửi phản hồi. Tách riêng các giai đoạn này thay vì chỉ đo tổng thời lượng. Hai yêu cầu có cùng thời gian trôi qua có thể có nút thắt cổ chai khác nhau: một yêu cầu có thể chờ kết nối trong khi yêu cầu kia tiêu tốn thời gian bên trong truy vấn cơ sở dữ liệu.

Sử dụng định danh yêu cầu để tương quan các quan sát giữa các dịch vụ. W3C Trace Context định nghĩa chuẩn truyền vết, có thể giúp ghép các span từ những thành phần bạn đã gắn công cụ. Một span bị thiếu không phải là bằng chứng rằng không có công việc nào đã xảy ra; hãy xác minh lấy mẫu, truyền vết và phạm vi ghi log trước khi diễn giải khoảng trống đó.

So sánh một yêu cầu lỗi với một yêu cầu thành công có chi phí tương tự. Khớp route, kích thước đầu vào, ngữ cảnh tenant và phiên bản triển khai khi khả thi. Một endpoint kiểm tra sức khỏe nhanh là một so sánh tồi cho một thao tác xuất dữ liệu tốn kém, và một lần đọc có cache có thể tránh đúng phụ thuộc chịu trách nhiệm gây ra timeout.

Nguồn gốc phổ biến của độ trễ thượng nguồn

Độ trễ thượng nguồn thường đến từ một phụ thuộc bị giới hạn hơn là bản thân gateway. Khóa cơ sở dữ liệu có thể giữ một yêu cầu ứng dụng mà không cần dùng nhiều CPU. Một dịch vụ bên ngoài có thể tiêu tốn phần lớn ngân sách phản hồi. Một pool kết nối có thể khiến công việc phải chờ trước khi bất kỳ cuộc gọi phụ thuộc nào bắt đầu.

Tính toán của ứng dụng là một khả năng khác. Một yêu cầu quét một tập dữ liệu lớn hoặc tạo một bản xuất dữ liệu khổng lồ có thể vượt quá ngân sách dự kiến cho đường đi đồng bộ. Tăng thời gian chờ của gateway có thể giúp một số yêu cầu hoàn tất, nhưng nó cũng có thể giữ kết nối và worker lâu hơn và làm trầm trọng thêm tình trạng xếp hàng cho lưu lượng thông thường.

Sự cố mạng nên được điều tra với bằng chứng theo từng giai đoạn. Phân giải chậm, thiết lập kết nối hoặc truyền phản hồi là những vấn đề khác biệt với thực thi ứng dụng. Ghi lại điểm đích và thời gian kết nối liên quan, sau đó mời bên sở hữu mạng tham gia khi bằng chứng cho thấy vấn đề nằm ngoài ứng dụng.

Các thời hạn lồng nhau cần một ngân sách mạch lạc

Các thời hạn lồng nhau nên chừa đủ thời gian để mỗi thành phần trả về một kết quả có ý nghĩa cho bên gọi của nó. Một client, gateway, ứng dụng và phụ thuộc có thể mỗi bên giám sát một khoảng thời gian khác nhau. Thời hạn áp dụng sớm nhất kiểm soát những gì người dùng nhìn thấy, trong khi công việc ở một tầng khác có thể vẫn đang chạy.

Lập bản đồ các ngân sách đã cấu hình và phạm vi của chúng. Thời gian chờ kết nối bao phủ một phần công việc khác với thời hạn tổng thể của một yêu cầu. Thời gian chờ đọc có thể điều chỉnh các khoảng trống trong truyền dữ liệu thay vì toàn bộ thao tác, tùy thuộc vào client. Hãy sử dụng hợp đồng thành phần thực tế thay vì giả định mọi thiết lập được gọi là thời gian chờ đều đo cùng một khoảng thời gian.

Dành thời gian dự phòng cho việc dọn dẹp và gửi phản hồi khi thiết kế hạn chót cho một ứng dụng. Nếu một phụ thuộc có thể sử dụng hết toàn bộ ngân sách bên ngoài, ứng dụng có thể không còn cơ hội để trả về một phản hồi giải thích. Một ngân sách mạch lạc giúp cho thao tác giới hạn trở nên rõ ràng và tránh để các tác vụ tốn kém tiếp tục chạy sau khi bên gọi đã ngừng chờ đợi.

Tại sao Thời gian chờ Cổng lớn hơn Có thể Không Giúp

Thời gian chờ cổng (gateway timeout) lớn hơn chỉ hữu ích khi thao tác phía upstream là hợp lệ, có giới hạn và được kỳ vọng sẽ hoàn thành trong ngân sách thời gian đã điều chỉnh. Nó không khắc phục được bế tắc, backend vắng mặt hoặc một phụ thuộc không bao giờ phản hồi. Hãy đo lường hành vi hoàn thành trước khi quyết định rằng việc chờ lâu hơn là phù hợp.

Hãy xem xét một endpoint báo cáo minh họa thực hiện một tác vụ xuất lớn theo cách đồng bộ. Việc tăng giới hạn của gateway có thể cho phép một tác vụ xuất nhỏ hoàn thành trong khi những tác vụ lớn hơn vẫn thất bại. Câu hỏi vận hành đặt ra là liệu các tác vụ xuất có thuộc về một tương tác yêu cầu–phản hồi hay không. Một job bất đồng bộ với một tài nguyên trạng thái có thể làm cho tiến trình và việc hoàn thành trở nên rõ ràng khi sản phẩm hỗ trợ thiết kế đó.

Cũng hãy kiểm tra thời hạn của người gọi. Nếu người gọi ngừng chờ trước khi giới hạn mới của cổng được áp dụng, thì thay đổi này có thể chỉ khiến tài nguyên máy chủ bị chiếm dụng lâu hơn. Việc thay đổi thời hạn cần được xem xét trên toàn bộ tuyến yêu cầu và được đánh giá dựa trên mức độ chiếm dụng tài nguyên cũng như tỷ lệ thành công.

Phân biệt 504 với hết thời gian chờ cục bộ và 522

Hết thời gian chờ cục bộ có nghĩa là client đã kết thúc việc chờ đợi; mã 504 có nghĩa là client đã nhận được phản hồi hết thời gian chờ từ một gateway. Giữ nguyên trạng thái HTTP null hoặc vắng mặt khi không nhận được bất kỳ phản hồi nào. Gán 504 cho mọi ngoại lệ phía client sẽ tạo ra số lượng sự cố sai lệch và có thể khiến cuộc điều tra tập trung vào một gateway vốn không hề trả về bất cứ thứ gì.

Cloudflare 522 liên quan đến việc Cloudflare giao tiếp với máy chủ gốc tại một ranh giới khác. Nó nên giữ nguyên danh mục riêng của nó thay vì được đổi tên thành 504 cho thuận tiện. Một bộ thu thập có thể nhóm cả hai vào mục các quan sát không khả dụng trong khi vẫn giữ nguyên các bằng chứng kỹ thuật riêng biệt của chúng ở bên dưới.

Điều hướng trình duyệt và chờ phần tử bổ sung thêm một lớp nữa. Một trình duyệt có thể nhận một trang 504 và sau đó hết thời gian chờ khi đợi một phần tử nội dung. Hãy kiểm tra phản hồi của trang trước khi coi ngoại lệ tự động hóa thu được là một lỗi kết xuất riêng biệt. Lỗi có ý nghĩa sớm nhất thường giải thích các triệu chứng xuất hiện sau đó.

Một Lần Hết Thời Gian Chờ Không Phải Lúc Nào Cũng Thể Hiện Kết Quả Của Một Lần Ghi

Một yêu cầu thay đổi trạng thái bị hết thời gian chờ có thể khiến bên gọi không chắc chắn liệu thao tác đã hoàn tất hay chưa. Cổng gateway có thể ngừng chờ trong khi một ứng dụng hoặc thành phần phụ thuộc vẫn tiếp tục xử lý. Do đó, chỉ lỗi hiển thị cho người dùng là không đủ để quyết định liệu một đơn đặt hàng, bản cập nhật, hoặc việc tạo tác vụ đã xảy ra hay chưa.

Sử dụng mã định danh của thao tác hoặc bản ghi ứng dụng có thẩm quyền để xử lý sự không chắc chắn. Các hệ thống hỗ trợ tính idempotent cần áp dụng đúng hợp đồng đã được tài liệu hóa, bao gồm phạm vi và thời hạn hiệu lực của mã định danh. Không được giả định rằng một header bất kỳ sẽ tạo ra tính idempotent hoặc rằng mọi endpoint ghi đều triển khai cùng một hành vi.

Trong một báo cáo sự cố, hãy phân biệt “không nhận được phản hồi” với “thao tác đã không diễn ra”. Cách diễn đạt đó rất quan trọng cho hỗ trợ và đối soát. Một lần đọc được xác nhận là thất bại và một lần ghi không chắc chắn có thể cùng chia sẻ triệu chứng hết thời gian chờ, nhưng lại yêu cầu những hành động tiếp theo rất khác nhau.

Xác thực cả tính mới và nội dung trong thu thập dữ liệu

Một quy trình thu thập chỉ nên chấp nhận dữ liệu sau khi kiểm tra kết quả mục tiêu và nội dung bắt buộc. Một trang lỗi 504 có thể được trả về dưới dạng văn bản thông thường hoặc HTML bên trong phản hồi của một dịch vụ khác. Một bộ phân tích cú pháp trích xuất thành công phần nội dung đó vẫn chưa thu thập được bản ghi nghiệp vụ dự định.

Bộ nhớ đệm bổ sung thêm một sự phân biệt khác. Ngữ nghĩa bộ nhớ đệm HTTP mô tả việc tái sử dụng các phản hồi đã lưu theo những quy tắc rõ ràng. Một phản hồi cũ nhưng thành công có thể hữu ích trong một số quy trình làm việc, nhưng nó phải giữ được ngữ cảnh về tính thời sự của nó. Không được trình bày dữ liệu đã thu thập trước đó như một quan sát mới chỉ vì nó có sẵn trong thời gian ngừng hoạt động.

Giữ các trường riêng biệt cho thời gian thu thập, thời gian quan sát nguồn, trạng thái phản hồi và kết quả xác thực khi quy trình làm việc cần chúng. Người dùng ở các bước sau đó có thể tự quyết định liệu dữ liệu cũ có chấp nhận được hay không. Lớp thu thập không nên làm cho quyết định đó trở nên không nhìn thấy được bằng cách gộp tất cả văn bản hiện có vào một kết quả được coi là thành công.

Web Unlocker Có Ranh Giới Thực Thi Riêng Của Nó

Trình Mở Khóa Web cung cấp một lớp truy xuất được quản lý, và việc/khả năng đó chính sách thời gian chờ phân biệt việc tải trang với việc thực thi lũy kế các lệnh. Các giới hạn dịch vụ đó tách biệt với thời hạn của cổng đích và ngân sách tổng thể của tác vụ phía máy khách của bạn. Việc tăng một thiết lập phía máy khách không thể ghi đè thời hạn do phía đích kiểm soát.

The Thảo luận về dấu vân tay của HTTP client và trình duyệt minh họa lý do tại sao các đường dẫn truy xuất khác nhau lại có hành vi khác nhau, nhưng lựa chọn phương thức truyền tải không phải là cách khắc phục cho một cơ sở dữ liệu đích bị quá tải. Hãy chọn giao diện truy xuất đã được ghi chép cho nội dung bạn cần, rồi kiểm tra kết quả ở từng lớp liên quan.

Use current Giá không cần thu thập dữ liệu lên kế hoạch cho công việc thu thập đủ điều kiện và giữ cho các giới hạn về năng lực được thể hiện rõ ràng. Khi một nguồn thượng nguồn bị suy giảm, hãy ngừng chấp nhận các tác vụ không cần thiết cho phạm vi đó và bảo toàn bằng chứng cần thiết cho chủ sở hữu của nó. Một hàng đợi lớn hơn gồm các yêu cầu bị treo giống hệt nhau làm tăng chi phí mà không giải thích được độ trễ ban đầu.

Kết luận

HTTP 504 là một manh mối về một ranh giới chờ đợi ở thượng nguồn. Tìm cổng (gateway) phát ra, dựng lại mốc thời gian và so sánh các thời hạn lồng nhau với công việc thực tế. Sửa chữa nút thắt cổ chai được đo lường và xác minh hoạt động dự định, đồng thời giữ cho các lần ghi không chắc chắn và dữ liệu thu thập bị thiếu luôn hiển thị.