ما در حال حاضر در حال انتقال زیرمجموعه ای از انواع گزارش از آفلاین به گزارش فوری هستیم. پس از انتقال کاربر، پاسخ‌های queries.list شامل گزارش‌های فوری موجود می‌شود. برای اطلاعات بیشتر به پست وبلاگ ما مراجعه کنید.
با مجموعهها، منظم بمانید
ذخیره و دستهبندی محتوا براساس اولویتهای شما.
سهمیه‌ها از زیرساخت Google در برابر فرآیندهای خودکاری که از Google Bid Manager API به روشی نامناسب استفاده می‌کنند محافظت می‌کند. آنها اطمینان می دهند که اقدامات یک توسعه دهنده نمی تواند تأثیر منفی بر جامعه بزرگتر بگذارد.
محدودیت های سهمیه
محدودیت‌های سهمیه پیش‌فرض زیر توسط همه منابع و روش‌های Bid Manager API مشترک است.
در Google API Console این سهمیه به عنوان Queries در دقیقه برای هر کاربر نامیده می شود و روی 240 تنظیم شده است.
فراتر از حد نصاب
در صورتی که درخواست شما به دلیل فراتر رفتن از حد مجاز ناموفق باشد، API یک کد وضعیت HTTP و دلیل خطا را برمی‌گرداند. علاوه بر این، بدنه پاسخ حاوی شرح مفصلی از آنچه باعث خطا شده است. برای نمونه پاسخ خطا به راهنمای پیام های خطا مراجعه کنید.
لیست زیر خطاهای احتمالی و اقدامات توصیه شده برای شکست درخواست ناشی از فراتر از حد مجاز را نشان می دهد.
سرعت ارسال درخواست ها را با استفاده از عقب نشینی نمایی کاهش دهید.
عقب نشینی نمایی چیست؟
عقب نشینی نمایی یک استراتژی استاندارد مدیریت خطا برای برنامه های کاربردی شبکه است که در آن کلاینت به طور دوره ای یک درخواست ناموفق را در مدت زمان فزاینده ای تکرار می کند. اگر حجم بالای درخواست‌ها یا ترافیک شبکه سنگین باعث شود سرور خطاها را برگرداند، پس‌انداز نمایی ممکن است استراتژی خوبی برای رسیدگی به این خطاها باشد. برعکس، این یک استراتژی مناسب برای برخورد با خطاهای غیرمرتبط با حجم شبکه یا زمان پاسخ، مانند اعتبارنامه های مجوز نامعتبر یا خطاهای یافت نشدن فایل نیست.
اگر به درستی استفاده شود، پس‌انداز نمایی کارایی استفاده از پهنای باند را افزایش می‌دهد، تعداد درخواست‌های مورد نیاز برای دریافت پاسخ موفقیت‌آمیز را کاهش می‌دهد و توان عملیاتی درخواست‌ها را در محیط‌های همزمان به حداکثر می‌رساند.
جریان برای پیاده سازی عقب نشینی نمایی ساده به شرح زیر است:
یک درخواست به API بدهید.
پاسخ HTTP 503 را دریافت کنید، که نشان می دهد باید درخواست را دوباره امتحان کنید.
1 ثانیه + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
پاسخ HTTP 503 را دریافت کنید، که نشان می دهد باید درخواست را دوباره امتحان کنید.
2 ثانیه + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
پاسخ HTTP 503 را دریافت کنید، که نشان می دهد باید درخواست را دوباره امتحان کنید.
4 ثانیه + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
پاسخ HTTP 503 را دریافت کنید، که نشان می دهد باید درخواست را دوباره امتحان کنید.
۸ ثانیه + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
پاسخ HTTP 503 را دریافت کنید، که نشان می دهد باید درخواست را دوباره امتحان کنید.
16 ثانیه + random_number_milliseconds صبر کنید و دوباره درخواست را امتحان کنید.
متوقف کردن. یک خطا را گزارش یا ثبت کنید.
در جریان فوق، random_number_milliseconds تعداد تصادفی میلی‌ثانیه‌ها کمتر یا مساوی 1000 است. این امر ضروری است، زیرا وارد کردن یک تاخیر تصادفی کوچک به توزیع یکنواخت بار و جلوگیری از احتمال ضربه زدن به سرور کمک می‌کند. مقدار random_number_milliseconds باید بعد از هر انتظار دوباره تعریف شود.
توجه: انتظار همیشه (2 ^ n) + random_number_milliseconds است، که در آن n یک عدد صحیح افزایشی یکنواخت است که در ابتدا 0 تعریف شده است. عدد صحیح n برای هر تکرار (هر درخواست) 1 افزایش می یابد.
الگوریتم تنظیم شده است تا زمانی که n 5 باشد خاتمه یابد. این سقف مانع از تلاش مجدد مشتریان برای بی نهایت می شود و منجر به تأخیر کلی در حدود 32 ثانیه قبل از اینکه یک درخواست "خطایی غیرقابل جبران" تلقی شود، می شود. حداکثر تعداد بیشتری از تلاش های مجدد خوب است، به خصوص اگر یک آپلود طولانی در حال انجام باشد. فقط مطمئن شوید که تاخیر تلاش مجدد را در چیزی معقول، مثلاً کمتر از یک دقیقه محدود کنید.
درخواست سهمیه روزانه اضافی
اگر فکر می‌کنید که درخواست شما به سهمیه روزانه اضافی نیاز دارد، می‌توانید با دنبال کردن دستورالعمل‌های زیر بیشتر درخواست کنید.
دستورالعمل های زیر فقط برای پروژه هایی اعمال می شود که با خطای dailyLimitExceeded مواجه شده اند. اقدامات توصیه شده برای سایر خطاهای سهمیه در جدول بالا پوشش داده شده است.
آمار استفاده خود را از صفحه Metrics مرور کنید تا مطمئن شوید برنامه شما مطابق انتظار عمل می کند. قبل از ادامه، به روش هایی که فراخوانی شده اند دقت کنید و هرگونه استفاده غیرمنتظره یا بیش از حد را برطرف کنید.
اگر استفاده عادی به نظر می رسد، به صفحه سهمیه ها بروید، روی نماد ویرایش در کنار Queries per day کلیک کنید و روی پیوند "درخواست برای سهمیه بالاتر" کلیک کنید.
قبل از ارسال درخواست افزایش، حتماً اطلاعات را بررسی کرده و دستورالعمل‌های موجود در فرم درخواست سهمیه را دنبال کنید.
تاریخ آخرین بهروزرسانی 2024-10-30 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین بهروزرسانی 2024-10-30 بهوقت ساعت هماهنگ جهانی."],[[["Google Bid Manager API uses quotas to protect its infrastructure and ensure fair usage for all developers."],["Default quota limits include 2,000 requests per project per day and 4 queries per second per project."],["Exceeding quota limits results in specific error codes, requiring actions like reducing requests or using exponential backoff."],["Exponential backoff is a retry strategy for handling temporary errors by gradually increasing wait times between requests."],["Developers can request additional daily quota through the Google API Console if needed."]]],[]]
