Ba khoảng thời gian chờ cho ba API khác nhau

Tôi đã xây dựng các đường ống ETL cho ba trang danh mục vào tháng Tư. Mỗi trang sử dụng một API khác nhau: Steam, GitHub và HuggingFace.

Tôi phải thiết lập các khoảng thời gian chờ (sleep intervals) cho từng loại. Các con số, chế độ lỗi và cách xử lý lỗi đều khác nhau. Dưới đây là những gì tôi sử dụng và lý do tại sao.

Steam: Chờ 250ms

Tài liệu của Steam khá mơ hồ về giới hạn tốc độ (rate limits). Dữ liệu từ cộng đồng cho thấy khoảng 200 yêu cầu mỗi 5 phút cho mỗi IP. Điều này có nghĩa là khoảng thời gian chờ 1,5 giây là an toàn.

Thay vào đó, tôi sử dụng 250ms. Công việc chạy hàng đêm của tôi chỉ xử lý 60 mục trò chơi. Với 250ms, tổng thời gian chờ là 15 giây. Với 1,5 giây, nó sẽ lên tới 90 giây. Việc tiết kiệm thời gian rất quan trọng khi bạn xử lý nhiều trang web cùng lúc.

Nếu Steam trả về lỗi, công việc sẽ không dừng lại. Nó sẽ ghi lại lỗi và chuyển sang mục tiếp theo. Dữ liệu sẽ được cập nhật vào đêm hôm sau.

GitHub: Chờ 100ms

GitHub rất rõ ràng. Người dùng không xác thực được 60 yêu cầu mỗi giờ. Người dùng có token được 5.000 yêu cầu mỗi giờ.

Tôi sử dụng khoảng chờ 100ms như một biện pháp lịch sự. Token đóng vai trò chính trong việc xử lý giới hạn tốc độ. Đường ống của tôi sử dụng core REST API, không phải search API. Điều này cho phép mức giới hạn cao hơn nhiều.

HuggingFace: Không chờ

Tôi đã không chạm tới giới hạn tốc độ trong nhiều tuần chạy hàng đêm. Registry API được thiết kế cho các công cụ xử lý hàng loạt (batch tools) như của tôi.

Tôi lấy tối đa 100 mô hình cùng một lúc. Tôi sử dụng token xác thực để nâng giới hạn lên cao hơn nữa. Đối với 100 mô hình, không chờ là giải pháp đơn giản nhất.

Bảng tóm tắt:

• Steam: Chờ 250ms. Lỗi không nghiêm trọng (non-fatal errors). • GitHub: Chờ 100ms. Lỗi không nghiêm trọng. • HuggingFace: Không chờ. Lỗi không nghiêm trọng.

Khoảng thời gian chờ chỉ là một sự ước tính. Sự bảo vệ thực sự nằm ở cách tôi xử lý lỗi. Mọi lệnh gọi API đều sử dụng khối try/catch. Nếu một lệnh gọi thất bại, hệ thống sẽ ghi một hàng dự phòng (fallback row) thay vì bị sập.

Khoảng thời gian chờ kiểm soát tần suất bạn chạm tới giới hạn. Việc xử lý lỗi kiểm soát những gì xảy ra khi bạn chạm tới giới hạn đó.

Nguồn: https://dev.to/morinaga/three-sleep-intervals-for-three-apis-steam-250ms-github-100ms-huggingface-none-4ga7

Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi