تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تعمل الحصص على حماية بنية Google الأساسية من العمليات الآلية التي تستخدم Google Bid Manager API بطريقة غير ملائمة. وتضمن هذه القيود عدم تأثير إجراءات أحد مطوّري البرامج سلبًا في المنتدى الأكبر.
حدود الحصص
تتم مشاركة حدود الحصص التلقائية التالية بواسطة جميع موارد Bid Manager API وطرقها.
وفي وحدة تحكّم Google API، يُشار إلى هذه الحصة باسم طلبات البحث في الدقيقة لكل مستخدم، ويتم ضبطها على 240 طلب.
تم تجاوز حدود الحصة.
إذا تعذّر طلبك بسبب تجاوز أحد الحدود، وهو أمر مستبعد، ستعرض واجهة برمجة التطبيقات رمز حالة HTTP وسبب الخطأ. بالإضافة إلى ذلك، يتضمن نص الرد وصفًا تفصيليًا لسبب الخطأ. راجِع دليل رسائل الخطأ للاطّلاع على مثال عن الردّ على رسالة الخطأ.
تعرض القائمة التالية الأخطاء المحتملة والإجراءات المقترَحة لتعذُّر تنفيذ الطلبات بسبب تجاوز حدود الحصة.
الرمز
السبب
مراسلة
الإجراء المقترَح
403
dailyLimitExceeded
تم تجاوز الحد اليومي
يُرجى عدم إعادة المحاولة بدون حلّ المشكلة. تحقَّق من استخدامك من وحدة تحكّم Google API وعدِّل سير العمل لإجراء عدد أقل من الطلبات. يمكنك طلب حصة إضافية إذا كنت تعتقد أنّ استخدامك معقول.
403
userRateLimitExceeded
تم تجاوز حد معدل المستخدمين
يمكنك إبطاء معدل إرسال الطلبات باستخدام ميزة التراجع الدليلي.
ما معنى "التراجع الأُسيّ"؟
يعتبر التراجع التزايدي استراتيجية قياسية لمعالجة الأخطاء لتطبيقات الشبكة التي يعيد فيها العميل بشكل دوري محاولة تنفيذ طلب إخفاق على مدار فترة زمنية متزايدة. إذا تسببت كمية كبيرة من الطلبات أو حركة مرور بيانات الشبكة الكثيفة في عرض الخادم لأخطاء، فقد يكون التراجع الأسي استراتيجية جيدة للتعامل مع هذه الأخطاء. وبالعكس، فهي ليست استراتيجية مناسبة للتعامل مع الأخطاء غير المرتبطة بحجم الشبكة أو أوقات الاستجابة، مثل بيانات اعتماد التفويض غير الصالحة أو أخطاء "لم يتم العثور على الملف".
يؤدي استخدام ميزة "التراجع الأسي" إلى زيادة كفاءة استخدام معدل نقل البيانات، وتقليل عدد الطلبات المطلوبة للحصول على استجابة ناجحة، وزيادة سرعة معالجة الطلبات في البيئات المتزامنة.
في ما يلي الخطوات التي يجب اتّباعها لتنفيذ تراجع أسي بسيط:
يمكنك تقديم طلب إلى واجهة برمجة التطبيقات.
يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
يُرجى الانتظار لمدة ثانية واحدة مع قيمة عشوائية لـ العشوائي_number_milliseconds وإعادة محاولة الطلب.
يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
انتظِر لمدة ثانيتين مع إضافة عشوائي_number_milliseconds، وأعِد محاولة إجراء الطلب.
يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
انتظِر لمدة 4 ثوانٍ + العشوائي_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
انتظِر لمدة 8 ثوانٍ مع إضافة عشوائي_number_milliseconds، ثم أعِد محاولة إجراء الطلب.
يتم تلقّي استجابة HTTP 503، ما يشير إلى أنّه يجب إعادة محاولة الطلب.
انتظِر لمدة 16 ثانية بالإضافة إلى قيمة عشوائية قدرها 16 ثانية عشوائيًا، ثم أعِد محاولة إجراء الطلب.
إيقاف. الإبلاغ عن خطأ أو تسجيله
في التدفق أعلاه، alternate_number_milliseconds هو عدد عشوائي بالملي ثانية أقل من أو يساوي 1000. ويعد هذا أمرًا ضروريًا، نظرًا لأن إدخال تأخير عشوائي صغير يساعد في توزيع التحميل بشكل متساوٍ وتجنب إمكانية ختم الخادم. يجب إعادة تحديد قيمة عشوائية number_number_milliseconds بعد كل انتظار.
ملاحظة: يكون وقت الانتظار دائمًا (2 ^ n) + العشوائي_number_milliseconds، حيث يمثِّل n عددًا صحيحًا متزايدًا ويتضاعف مع تحديده في البداية على أنّه 0. تتم زيادة العدد الصحيح n بمقدار 1 لكل تكرار (كل طلب).
يتم تعيين الخوارزمية على الانتهاء عندما تكون n هي 5. ويمنع هذا الحد الأقصى للعملاء من تكرار المحاولة إلى ما لا نهاية، ويؤدي إلى تأخير إجمالي يصل إلى 32 ثانية تقريبًا قبل أن يتم تصنيف الطلب على أنه "خطأ لا يمكن إصلاحه". لا بأس في زيادة الحد الأقصى لعدد عمليات إعادة المحاولة، خاصةً إذا كان هناك تحميل طويل قيد التقدم؛ فقط تأكد من تحديد مدة تأخير إعادة المحاولة بأقل من دقيقة واحدة على سبيل المثال.
جارٍ طلب حصة يومية إضافية
إذا كنت تعتقد أنّ طلبك يتطلب حصة يومية إضافية، يمكنك طلب المزيد من خلال اتّباع التعليمات أدناه.
لا تنطبق التعليمات التالية إلا على المشاريع التي واجهت خطأ dailyLimitExceeded. يتضمّن الجدول أعلاه الإجراءات المقترَحة للأخطاء الأخرى المتعلّقة بالحصص.
راجِع إحصاءات الاستخدام من صفحة المقاييس للتأكّد من أنّ تطبيقك يعمل على النحو المتوقّع. يُرجى الانتباه جيدًا إلى الطرق التي تم الاتصال بها ومعالجة أي استخدام غير متوقع أو زائد قبل المتابعة.
إذا كان الاستخدام يبدو طبيعيًا، انتقِل إلى صفحة الحصص، وانقر على رمز التعديل بجانب طلبات البحث في اليوم، ثم انقر على الرابط "تقديم طلب للحصول على حصة أعلى".
احرص على مراجعة المعلومات واتّباع التعليمات المضمَّنة في نموذج طلب الحصة قبل إرسال طلب زيادة.
تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-31 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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."]]
