ForHosting KIT · قراءة المواقع ومراقبتها

حاسبة حد معدّل API

مع حد 100 استدعاء في الدقيقة، يتطلب إرسال 350 استدعاء 4 نوافذ: ثلاث دفعات من 100 ودفعة من 50، بفاصل 60 ثانية، وبمدة إجمالية لا تقل عن 180 ثانية. خطّط للاستيراد والمزامنة دون تجاوز حد المزوّد. مجاني في متصفحك.

  • مجاني
  • يعمل في متصفحك
  • دون تسجيل
  • بياناتك لا تغادر جهازك
استخدمها من الويبAPIالبريدTelegramالتطبيق قريبًا
إذا أدخلت
حد المعدل
100
الطلبات المطلوبة
350
ثواني النافذة
60
تحصل على
النوافذ المطلوبة
4
حجم الدفعة
100
حجم الدفعة الأخيرة
50
الدفعات الكاملة
3

وتعيد عدد النوافذ التي تحتاجونها، وأقصى حجم دفعة لا يتجاوز الحد، وحجم الدفعة الجزئية الأخيرة، والتأخير بين بدايات الدفعات، والحد الأدنى لزمن الساعة إن بدأتم الدفعة الأولى فوراً، والمعادل الأقصى للطلبات في الثانية.

كيف تُبقيكم النوافذ والدفعات والتأخير تحت الحد

يعني حد معدّل قدره R طلبات لكل نافذة طولها W ثانية أن المزوّد يقبل في أي نافذة منزلقة أو ثابتة طولها W ثانية على الأكثر R استدعاءات ناجحة. عندما تحتاجون D طلباً إجمالياً وD أكبر من R، لا يمكنكم إرسال كل شيء دفعة واحدة. الخطة الآمنة هي إرسال R طلباً على الأكثر في النافذة الأولى، وانتظار انقضاء نافذة كاملة، ثم إرسال الـ R التالية، وتكرار ذلك حتى ينفد الباقي.

عدد النوافذ المطلوبة هو سقف D مقسوماً على R. إذا كان D ثلاثمئة وخمسين وR مئة، تحتاجون أربع نوافذ: ثلاث دفعات كاملة بمئة ودفعة أخيرة بخمسين. يساوي التأخير بين بدايات الدفعات W عندما تُطلب أكثر من نافذة، ويساوي صفراً عندما تكفي نافذة واحدة.

يكون الحد الأدنى للزمن المنقضي عندئذ (عدد النوافذ ناقص واحد) مضروباً في W، لأن الدفعة الأولى يمكن أن تبدأ عند الزمن صفر والأخيرة تبدأ بعد الانتظارات السابقة. يطابق هذا النموذج الاستدلالات الشائعة للنافذة الثابتة وسلة الرموز في مكتبات العميل: وهو محافظ عمداً للنوافذ الثابتة وميزانية أولى متينة لسلال الرموز عندما لا تعيدون التعبئة وسط الاندفاع.

أين تفيد هذه الحاسبة في العمل اليومي

إدخال ذلك العدد مع حد معدّل المورّد في هذه الحاسبة ينتج جدول نوم يمكنكم وضعه في حلقة عامل دون عواصف 429 بالتجربة والخطأ. يمكن لمديري المنتجات الذين يقدّرون مدة تصدير جماعي أن يحوّلوا عدد وثائق إلى زمن ساعة حائط قبل وعد العميل بنافذة في اليوم نفسه. لا يستهلك فشل التحقق الرصيد.

أبقوا منطق الجدول في عميلكم؛ واستخدموا هذه النقطة الطرفية مصدراً وحيداً للحقيقة الحسابية حتى يخطط الجوال وعمال الحافة ومهام CI بالطريقة نفسها.

ماذا لو كان حد المعدّل صفراً أو سالباً؟

حد المعدّل غير الموجب ليس ميزانية صالحة والاستدعاء لا يُحاسب.

كم نافذة أحتاج لإرسال 350 استدعاء بحد 100؟

أربع نوافذ. اقسم 350 على 100 وقرّب إلى الأعلى: ثلاث دفعات كاملة من 100 ودفعة أخيرة من 50. الدفعة الأخيرة أصغر، لذا لا تتجاوز الحد أبدًا.

ما أقصر مدة تستغرقها المهمة كلها؟

عدد النوافذ ناقص واحد مضروبًا في طول النافذة. مع 4 نوافذ مدة كل منها 60 ثانية تكون المدة 180 ثانية، لأن الدفعة الأولى تنطلق فورًا ولا يضيف الوقت إلا الانتظار.

هل ترسل الحاسبة الاستدعاءات نيابةً عني؟

لا. فهي لا تتصل بالخدمة إطلاقًا، بل تحدد الجدول الزمني فقط، ويتولى برنامجك إرسال كل دفعة والانتظار المقترح قبل الدفعة التالية.

هل تصلح هذه الخطة لحدود دلو الرموز أيضًا؟

نعم، كميزانية أولى حذرة، ما دام الدلو لا يُعاد ملؤه في منتصف الدفعة. أما مع النوافذ الثابتة فالخطة متحفظة عن قصد، فتبقى تحت الحد بأمان.

كل ما في هذه الصفحة متاح برمجيًا. هذا القسم موجّه للفرق التقنية التي تريد ربط الأداة بأنظمتها الخاصة؛ بقية المستخدمين يمكنهم استخدام الأداة أعلاه مباشرة دون الحاجة لقراءة ما يلي.

POSThttps://api.kit.forhosting.com/dev/api-rate-limit-calc

صادِق على طلبك بترويسة Bearer، وأرسل طلب POST واحدًا لتدخل مهمتك قائمة التنفيذ فورًا؛ ثم تستلم النتيجة عبر webhook أو رابط موقّع.

curl -X POST https://api.kit.forhosting.com/dev/api-rate-limit-calc \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"rate_limit":100,"desired_requests":350}'
{
  "rate_limit": 100,
  "desired_requests": 350
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.api_rate_limit_calc",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

الواجهة غير متزامنة: تستلم task_id فور الإرسال، ويمكنك الاستعلام عن الحالة بمعدل طلب واحد في الثانية.

لكل طلب$0.002

السعر معلن كما تراه: لا tokens ولا نظام نقاط؛ وإن فشلت المهمة فلن تُحاسَب عليها.

HTTPالرمزالمعنى
401unauthorizedمفتاح الوصول مفقود أو غير صالح؛ تحقق من ترويسة Bearer في طلبك.
402insufficient_balanceرصيدك لا يكفي لتنفيذ هذه المهمة؛ أعد شحن الرصيد ثم أعد المحاولة.
404unknown_typeنوع المهمة المطلوب غير موجود في الكتالوج — راجع الاسم المرسل في الطلب.
429rate_limitedتجاوزت الحد المسموح من الطلبات؛ انتظر قليلًا ثم أعد المحاولة.

تنشر واجهات API العامة والخاصة تقريباً دائماً حد معدّل، مثل مئة طلب في الدقيقة أو ألف طلب في الساعة. من يحتاج إلى إرسال حركة أكبر مما تسمح به نافذة واحدة يجب أن يقسّم العمل إلى دفعات وينتظر بينها حتى لا يعيد المزوّد HTTP 429 أو يسحب الاعتمادات. تقبل حاسبة ميزانية حد معدّل API الحد الأقصى للطلبات لكل نافذة، وإجمالي الطلبات التي تعتزمون إرسالها، وطول النافذة بالثواني اختيارياً. الحساب خالص وحتمي: أداة المتصفح المجانية ومسار API المدفوع يشتركان في الوحدة نفسها، فلا يختلف اختبار الأتمتة عن التخطيط اليدوي. تفشل حدود المعدّل غير الموجبة بـ invalid_input ولا تُحاسب.

كيف تُبقيكم النوافذ والدفعات والتأخير تحت الحد

لا تستدعي الحاسبة الـ API البعيد؛ بل تقيس جدولكم فقط حتى ينام عميلكم بين الدفعات.

عقد الإدخال وحقول الاستجابة وقواعد التحقق

أرسلوا بهيئة POST جسماً JSON يتضمن rate_limit، وهو عدد صحيح موجب للطلبات المسموحة لكل نافذة؛ وdesired_requests، وهو عدد صحيح غير سالب للاستدعاءات التي تنوون تنفيذها؛ واختيارياً window_seconds، وهو طول موجب محدود لتلك النافذة بالثواني وقيمته الافتراضية ستون عند الحذف. قد يصل كل حقل كعدد JSON أو كسلسلة رقمية. تفشل الحقول الناقصة والقيم غير المحدودة وdesired_requests الكسري وrate_limit الكسري وأي rate_limit ليس موجباً بصرامة بـ invalid_input مع رسالة تسمّي الحقل. عند النجاح يعيد الجسم rate_limit وdesired_requests وwindow_seconds، ثم windows_needed وbatch_size (أقصى طلبات لكل دفعة كاملة، تساوي rate_limit ما دام العمل باقياً) وlast_batch_size (الدفعة الجزئية الختامية، أو دفعة كاملة عندما يقسم D بالضبط) وfull_batches (كم دفعة تستخدم الحجم الأقصى قبل الباقي) وdelay_between_batches_seconds وmin_elapsed_seconds وmax_requests_per_second كـ rate_limit مقسوماً على window_seconds، وسلسلة صيغة قصيرة تعيد قاعدة السقف. مثال: rate_limit مئة وdesired_requests ثلاثمئة وخمسون وwindow_seconds ستون يعطي أربع نوافذ وحجم دفعة مئة ودفعة أخيرة خمسين وتأخيراً ستين ثانية وحداً أدنى منقضياً مئة وثمانين ثانية. صفر desired_requests يعيد صفراً من النوافذ وصفراً من التأخير بلا خطأ، وهو مفيد لمخططي التشغيل الجاف.

أين تُثبت حاسبة ميزانية حد معدّل API فائدتها

غالباً ما تعرف سكربتات التكامل التي تملأ webhooks أو تعيد فهرسة وثائق البحث أو تُهاجر المستأجرين إجمالي العناصر قبل البدء. يمكن لأدوات الرصد والفوضى أن تؤكد أن مولّد حمل اصطناعي لا يتجاوز أبداً max_requests_per_second المشتق من الحد المنشور. تستفيد مواقع المحتوى التي ترتب لعبارات مثل حاسبة حد معدّل API من ودجة حية يطابق مسارها المجاني في المتصفح مسار الأتمتة المدفوع بايتاً ببايت على الوحدة النقية نفسها. ولأن التنفيذ parse من الطبقة A خالص، يكلف كل استدعاء ناجح السعر الأساسي المنشور $0.002 بلا رموز نموذج وبلا شبكة صادرة.

الترحيل الجماعي ومهام الملء الراجع

قسّموا عدداً معروفاً من الطلبات إلى دفعات آمنة ضمن حد المعدّل وناموا delay_between_batches_seconds بين كل بداية دفعة.

تقديرات SLA وكتب التشغيل

حوّلوا حدود معدّل المورّد إلى min_elapsed_seconds حتى تطابق خطط المناوبة وETAs العميل الخنق الفعلي.

أسقف اختبار الحمل والحركة الاصطناعية

اشتقوا max_requests_per_second من rate_limit وwindow_seconds قبل ضبط مولّدات يجب ألا تفعّل حراسات الإنتاج.

كيف أحسب عدد النوافذ اللازمة لحد معدّل API؟

أرسلوا rate_limit (طلبات صحيحة موجبة لكل نافذة) وdesired_requests (إجمالي الاستدعاءات) واختيارياً window_seconds (الافتراضي 60). windows_needed هو ceil(desired_requests / rate_limit).

ما التأخير الذي يجب انتظاره بين الدفعات؟

عندما تُطلب أكثر من نافذة، يساوي delay_between_batches_seconds قيمة window_seconds. وعندما تكفي نافذة واحدة يكون التأخير صفراً.

هل تستدعي الحاسبة API الخاصة بي أو تنام عني؟

لا. تعيد أرقام الجدول فقط. عميلكم يرسل الدفعات ويطبّق التأخير.

كم تكلفة حاسبة حد معدّل API؟

أداة المتصفح مجانية. تستخدم طلبات API رصيد KIT المدفوع مسبقاً بسعر $0.002 لكل استدعاء ناجح؛ والإدخال غير الصالح لا يُحاسب.

اطّلع على توثيق KIT الكامل ←