تعرّف على كيفية تطبيق LLM Resayil لحدود معدل الطلبات والحصص لضمان استخدام عادل واستقرار الخدمة. تعلّم كيف تتعامل مع استجابات تجاوز الحد وتطبّق استراتيجيات الانتظار التدريجي.
يُطبّق LLM Resayil حدوداً للمعدل لمنع الإساءة وضمان وصول عادل لجميع المستخدمين. تُطبَّق هذه الحدود على مستوى معرّف المستخدم في الدقيقة عبر Laravel RateLimiter.
تُحسب الحدود بتوقيت UTC. تتجدد حصتك في بداية كل دقيقة. عند تجاوز الحد، ستتلقى استجابة 429 Too Many Requests وعليك الانتظار حتى تتجدد الحصة قبل إعادة المحاولة.
ملاحظة: يتجاوز المستخدمون ذوو صلاحية المدير (Admin) حدود المعدل تلقائياً. تواصل مع الدعم إذا كنت بحاجة إلى حدود أعلى لحالات الاستخدام المشروعة.
تعتمد حدود معدل الطلبات على مستوى اشتراكك. فيما يلي ملخص لحدود كل مستوى:
| المستوى | طلبات/دقيقة | طلبات/يوم | أقصى رموز/طلب |
|---|---|---|---|
| Basic | 10 | — | — |
| Pro | 30 | — | — |
| Enterprise | 60 | — | — |
عند تجاوز حد المعدل، ستتلقى استجابة HTTP برمز الحالة 429 Too Many Requests.
تتضمن الاستجابة حقل retry_after الذي يحدد عدد الثواني اللازمة للانتظار قبل إعادة المحاولة:
HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 20
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1741305600
{
"error": {
"message": "Rate limit exceeded",
"code": 429
},
"retry_after": 45
}
تحقق من رؤوس HTTP هذه في كل استجابة لمراقبة استخدامك وتجنب الوصول إلى الحد:
| Header | الوصف |
|---|---|
| X-RateLimit-Limit | الحد الأقصى للطلبات في الدقيقة لمستواك (مثلاً: 20) |
| X-RateLimit-Remaining | عدد الطلبات المتبقية في الدقيقة الحالية |
| X-RateLimit-Reset | طابع زمني Unix يحدد موعد تجديد الحصة |
| retry_after | عدد الثواني التي يجب الانتظارها قبل إعادة المحاولة (في جسم الاستجابة) |
راقب الرأس X-RateLimit-Remaining في كل استجابة لتنفيذ تقنين استباقي من جانب العميل:
const response = await fetch(apiUrl, options);
const remaining = parseInt(response.headers.get('X-RateLimit-Remaining'), 10);
const limit = parseInt(response.headers.get('X-RateLimit-Limit'), 10);
if (remaining < limit * 0.2) {
console.warn(`Only ${remaining} requests remaining in this window!`);
}
عند تلقّي استجابة 429، استخدم قيمة retry_after الموجودة في جسم JSON
لتحديد مدة الانتظار. لا تُعيد المحاولة فوراً — انتظر المدة المحددة على الأقل.
import time
import requests
def call_with_retry(url, payload, headers, max_retries=5):
for attempt in range(max_retries):
response = requests.post(url, json=payload, headers=headers)
if response.status_code == 200:
return response.json()
if response.status_code == 429:
data = response.json()
retry_after = data.get("retry_after", 60)
print(f"Rate limited. Waiting {retry_after}s (attempt {attempt + 1})")
time.sleep(retry_after)
continue
response.raise_for_status()
raise Exception("Max retries exceeded")
عند تجاوز حد المعدل، نفّذ انتظاراً تدريجياً أسياً مع عشوائية لإعادة الطلبات بشكل موثوق. هذا الأسلوب أكثر موثوقية من إعادة المحاولة الفورية ويساعد في توزيع الحمل.
الأسلوب الموصى به هو الانتظار الأسي مع عشوائية لتجنب مشكلة "القطيع الرعدي":
import time
import random
def make_api_call_with_backoff(api_url, data, max_retries=5):
for attempt in range(max_retries):
try:
response = requests.post(api_url, json=data, timeout=10)
if response.status_code == 200:
return response.json()
elif response.status_code == 429:
# Use retry_after from body if available, else exponential backoff
body = response.json()
wait_time = body.get("retry_after") or (2 ** attempt) + random.uniform(0, 1)
print(f"Rate limited. Waiting {wait_time:.1f} seconds...")
time.sleep(wait_time)
else:
response.raise_for_status()
except Exception as e:
if attempt < max_retries - 1:
wait_time = (2 ** attempt) + random.uniform(0, 1)
time.sleep(wait_time)
else:
raise
raise Exception("Max retries exceeded")
ادمج عدة طلبات في استدعاء API واحد كلما أمكن. هذا يُعدّ طلباً واحداً نحو حصتك مع معالجة بيانات أكثر.
لا تعتمد فقط على تقنين الخادم. نفّذ تقنيناً من جانب العميل للبقاء ضمن 80% من حصتك:
// Limit to 80% of max requests to stay safe
const MAX_SAFE_RATE = 0.8;
const maxRequestsPerMinute = 20; // Your tier limit
const safeRate = maxRequestsPerMinute * MAX_SAFE_RATE; // 16 req/min
const delayBetweenRequests = 60000 / safeRate; // ~3750ms
خزّن استجابات API مؤقتاً لتجنب تكرار الطلبات على نفس الاستفسارات. هذا يُقلل استخدام API بشكل كبير ويبقيك ضمن حدود المعدل.
عند الحاجة لمعالجة كميات كبيرة من البيانات، وزّع الطلبات على مدار الوقت بدلاً من إرسالها دفعة واحدة. هذا يمنع انتهاك حدود الدفعات مع الحفاظ على معدل إنتاج ثابت.
أعدّ تنبيهات في تطبيقك عندما ينخفض X-RateLimit-Remaining
إلى أقل من 20% من حدك. يمنحك هذا إنذاراً مبكراً لاتخاذ الإجراء قبل ظهور أخطاء 429.
إذا كان تطبيقك يحتاج فعلاً إلى حدود أعلى، رقّ مستوى اشتراكك أو تواصل مع الدعم للحلول المؤسسية. من الأفضل الاستباقية على تجربة تدهور الخدمة.