Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Hạn mức giúp bảo vệ cơ sở hạ tầng của Google khỏi các quy trình tự động sử dụng API Trình quản lý giá thầu của Google theo cách không phù hợp. Chúng giúp đảm bảo rằng hành động của một nhà phát triển không được gây ảnh hưởng tiêu cực đến cộng đồng lớn hơn.
Hạn mức
Các hạn mức mặc định sau đây được áp dụng chung cho tất cả các tài nguyên và phương pháp của API Trình quản lý giá thầu.
Trong Google API Console, hạn mức này được gọi là Số truy vấn mỗi phút trên mỗi người dùng và được đặt là 240.
Vượt quá hạn mức
Trong trường hợp hiếm gặp là yêu cầu của bạn không thành công do vượt quá giới hạn hạn mức, API sẽ trả về mã trạng thái HTTP và lý do lỗi. Ngoài ra, phần nội dung của phản hồi chứa nội dung mô tả chi tiết về nguyên nhân gây ra lỗi. Xem hướng dẫn về Thông báo lỗi để xem ví dụ về phản hồi lỗi.
Danh sách sau đây cho thấy các lỗi có thể xảy ra và hành động được đề xuất cho các yêu cầu không thành công do vượt quá hạn mức.
Mã
Lý do
Thông điệp
Việc nên làm
403
dailyLimitExceeded
Đã vượt quá giới hạn hàng ngày
Đừng thử lại khi chưa khắc phục vấn đề. Kiểm tra mức sử dụng của bạn từ Google API Console và sửa đổi quy trình làm việc để đưa ra ít yêu cầu hơn. Bạn có thể yêu cầu bổ sung hạn mức nếu cho rằng mức sử dụng của mình là hợp lý.
Thuật toán thời gian đợi luỹ thừa là một chiến lược xử lý lỗi tiêu chuẩn cho các ứng dụng mạng, trong đó ứng dụng khách định kỳ thử lại một yêu cầu không thành công trong khoảng thời gian tăng dần. Nếu một lượng lớn yêu cầu hoặc lưu lượng truy cập mạng lớn khiến máy chủ trả về lỗi, thì thời gian đợi luỹ thừa có thể là một chiến lược tốt để xử lý những lỗi đó. Ngược lại, giải pháp này không phải là chiến lược phù hợp để xử lý các lỗi không liên quan đến lưu lượng truy cập mạng hoặc thời gian phản hồi, chẳng hạn như thông tin xác thực uỷ quyền không hợp lệ hoặc lỗi không tìm thấy tệp.
Được sử dụng đúng cách, thuật toán thời gian đợi luỹ thừa tăng hiệu quả sử dụng băng thông, giảm số lượng yêu cầu cần thiết để nhận được phản hồi thành công và tối đa hoá thông lượng yêu cầu trong các môi trường đồng thời.
Quy trình triển khai thuật toán thời gian đợi lũy thừa đơn giản như sau:
Tạo một yêu cầu đối với API.
Nhận phản hồi HTTP 503, cho biết bạn nên thử lại yêu cầu.
Đợi 1 giây + random_number_milliseconds rồi thử lại yêu cầu.
Nhận phản hồi HTTP 503, cho biết bạn nên thử lại yêu cầu.
Đợi 2 giây + random_number_milliseconds rồi thử lại yêu cầu.
Nhận phản hồi HTTP 503, cho biết bạn nên thử lại yêu cầu.
Đợi 4 giây + random_number_milliseconds rồi thử lại yêu cầu.
Nhận phản hồi HTTP 503, cho biết bạn nên thử lại yêu cầu.
Đợi 8 giây + random_number_milliseconds rồi thử lại yêu cầu.
Nhận phản hồi HTTP 503, cho biết bạn nên thử lại yêu cầu.
Đợi 16 giây + random_number_milliseconds rồi thử lại yêu cầu.
Dừng. Báo cáo hoặc ghi lại một lỗi.
Trong luồng trên, random_number_milliseconds là một số mili giây ngẫu nhiên nhỏ hơn hoặc bằng 1000. Điều này là cần thiết vì việc áp dụng độ trễ ngẫu nhiên nhỏ giúp phân phối tải đồng đều hơn và tránh khả năng làm hỏng máy chủ. Giá trị của random_number_mili giây phải được xác định lại sau mỗi lần chờ.
Lưu ý: Thời gian chờ luôn là (2 ^ n) + random_number_mili giây, trong đó n là một số nguyên tăng đơn điệu ban đầu được xác định là 0. Số nguyên n được tăng thêm 1 cho mỗi lần lặp (mỗi yêu cầu).
Thuật toán sẽ được đặt để kết thúc khi n là 5. Mức trần này ngăn ứng dụng thử lại vô hạn và dẫn đến tổng độ trễ khoảng 32 giây trước khi một yêu cầu được coi là "lỗi không thể khôi phục". Bạn có thể thử lại nhiều lần hơn, đặc biệt là khi quá trình tải lên trong thời gian dài đang diễn ra. Chỉ cần đảm bảo giới hạn thời gian thử lại ở mức hợp lý, chẳng hạn như dưới 1 phút.
Yêu cầu hạn mức bổ sung hằng ngày
Nếu cho rằng ứng dụng của mình cần có hạn mức bổ sung hằng ngày, bạn có thể yêu cầu tăng hạn mức hằng ngày bằng cách làm theo hướng dẫn bên dưới.
Hướng dẫn sau đây chỉ áp dụng cho những dự án gặp lỗi dailyLimitExceeded. Các hành động được đề xuất cho các lỗi khác về hạn mức được đề cập trong bảng trên.
Xem lại số liệu thống kê về việc sử dụng trên trang Chỉ số để đảm bảo ứng dụng của bạn đang hoạt động như mong đợi. Hãy chú ý kỹ đến các phương thức đã được gọi và giải quyết mọi trường hợp sử dụng quá mức hoặc ngoài dự kiến trước khi tiếp tục.
Nếu việc sử dụng có vẻ bình thường, hãy chuyển đến trang Hạn mức, nhấp vào biểu tượng chỉnh sửa bên cạnh mục Cụm từ tìm kiếm mỗi ngày rồi nhấp vào đường liên kết để "Đăng ký định mức cao hơn".
Hãy nhớ xem lại thông tin và làm theo hướng dẫn có trong biểu mẫu yêu cầu tăng hạn mức trước khi gửi yêu cầu tăng hạn mức.
[null,null,["Cập nhật lần gần đây nhất: 2025-08-31 UTC."],[[["\u003cp\u003eGoogle Bid Manager API uses quotas to protect its infrastructure and ensure fair usage for all developers.\u003c/p\u003e\n"],["\u003cp\u003eDefault quota limits include 2,000 requests per project per day and 4 queries per second per project.\u003c/p\u003e\n"],["\u003cp\u003eExceeding quota limits results in specific error codes, requiring actions like reducing requests or using exponential backoff.\u003c/p\u003e\n"],["\u003cp\u003eExponential backoff is a retry strategy for handling temporary errors by gradually increasing wait times between requests.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can request additional daily quota through the Google API Console if needed.\u003c/p\u003e\n"]]],["Google Bid Manager API uses quotas to protect its infrastructure, limiting projects to 2,000 daily requests and 4 queries per second. Exceeding these results in errors; `dailyLimitExceeded` requires usage examination and possible quota increase, while `userRateLimitExceeded` needs rate slowdown via exponential backoff. Exponential backoff retries failed requests with increasing delays (e.g., 1, 2, 4 seconds) and randomized milliseconds, terminating after a set number of attempts. Additional daily quota can be requested through the Google API Console.\n"],null,["# Quotas protect Google's infrastructure from automated processes that use the Google Bid Manager API in an inappropriate way. They ensure that one developer's actions cannot negatively impact the larger community.\n\nQuota limits\n------------\n\nThe following default quota limits are shared by all Bid Manager API resources and methods.\n\n- 2,000 requests per project per day - [can be increased](#additional_quota).\n- 4 queries per second (QPS) per project.\n - In the Google API Console this quota is referred to as **Queries per minute per user**, and is set to 240.\n\n| **Note:** Daily quotas refresh at midnight PST.\n\nExceeding quota limits\n----------------------\n\nIn the unlikely event that your request fails due to exceeding a quota limit, the API returns an HTTP status code and reason for the error. Additionally, the body of the response contains a detailed description of what caused the error. See the [Error Messages](/bid-manager/core_errors) guide for an example error response.\n\nThe following list shows the possible errors and recommended actions for request failures caused by exceeding quota limits.\n\n| Code | Reason | Message | Recommended Action |\n|------|-----------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| 403 | dailyLimitExceeded | Daily Limit Exceeded | Do not retry without fixing the problem. [Examine your usage](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/metrics) from the Google API Console and modify your workflow to make fewer requests. You can [request additional quota](#additional_quota) if you believe your usage is reasonable. |\n| 403 | userRateLimitExceeded | User Rate Limit Exceeded | Slow down the rate at which you are sending requests using [exponential backoff](#exponential_backoff). |\n\n#### What is exponential backoff?\n\nExponential backoff is a standard error handling strategy for network applications in which the client periodically retries a failed request over an increasing amount of time. If a high volume of requests or heavy network traffic causes the server to return errors, exponential backoff may be a good strategy for handling those errors. Conversely, it is not a relevant strategy for dealing with errors unrelated to network volume or response times, such as invalid authorization credentials or file not found errors.\n\nUsed properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.\n\nThe flow for implementing simple exponential backoff is as follows:\n\n1. Make a request to the API.\n2. Receive an `HTTP 503` response, which indicates you should retry the request.\n3. Wait 1 second + random_number_milliseconds and retry the request.\n4. Receive an `HTTP 503` response, which indicates you should retry the request.\n5. Wait 2 seconds + random_number_milliseconds, and retry the request.\n6. Receive an `HTTP 503` response, which indicates you should retry the request.\n7. Wait 4 seconds + random_number_milliseconds, and retry the request.\n8. Receive an `HTTP 503` response, which indicates you should retry the request.\n9. Wait 8 seconds + random_number_milliseconds, and retry the request.\n10. Receive an `HTTP 503` response, which indicates you should retry the request.\n11. Wait 16 seconds + random_number_milliseconds, and retry the request.\n12. Stop. Report or log an error.\n\nIn the above flow, random_number_milliseconds is a random number of milliseconds less than or equal to 1000. This is necessary, since introducing a small random delay helps distribute the load more evenly and avoid the possibility of stampeding the server. The value of random_number_milliseconds must be redefined after each wait.\n\n**Note:**The wait is always (2 \\^ n) + random_number_milliseconds, where n is a monotonically increasing integer initially defined as 0. The integer n is incremented by 1 for each iteration (each request).\n\nThe algorithm is set to terminate when n is 5. This ceiling prevents clients from retrying infinitely, and results in a total delay of around 32 seconds before a request is deemed \"an unrecoverable error.\" A larger maximum number of retries is fine, especially if a long upload is in progress; just be sure to cap the retry delay at something reasonable, say, less than one minute.\n\nRequesting additional daily quota\n---------------------------------\n\nIf you think that your application requires additional daily quota, you can request more by following the instructions below.\n\nThe following instructions only apply to projects that have encountered a `dailyLimitExceeded` error. Recommended actions for other quota errors are covered in the [table above](#exceeding_limits).\n\n1. Navigate to the [Bid Manager API](https://console.developers.google.com/project/_/apiui/apiview/doubleclickbidmanager/quotas) in the Google API Console.\n2. Review your usage statistics from the **Metrics** page to ensure your application is behaving as expected. Pay close attention to the methods that have been called and address any unexpected or excessive usage before proceeding.\n3. If usage looks normal, navigate to the **Quotas** page, click the edit icon next to **Queries per day** and click the link to \"Apply for higher quota\".\n\nMake sure to review the information and follow the instructions included in the quota request form before submitting an increase request.\n| **Note:** The email address you provide must be one that you actively monitor, as a representative may reach out to gather additional information."]]
