ما معنى مهلة طلب المنبع وكيفية إصلاحها؟

تخيل هذا: لقد قمت للتو بنشر ميزة جديدة رائعة. رمزك نظيف، واختباراتك ناجحة، وتشعر وكأنك ساحر في البرمجة. تتكئ على كرسيك، تتناول رشفة من قهوتك، وتقرر إجراء اختبار واقعي. تنقر على الزر، يظهر مؤشر التحميل، ثم... لا شيء. المؤشر يستمر في الدوران فقط. بعد ما يبدو وكأنه أبدية، تستقبلك رسالة خطأ صارخة وغير ودية في متصفحك: "504 Gateway Timeout" أو، بشكل أكثر غموضًا، في سجلاتك: "upstream request timeout". إذا قضيت أي وقت في العمل مع واجهات برمجة التطبيقات (APIs)، أو الوكلاء العكسيين (reverse proxies)، أو الخدمات المصغرة (microservices)، فمن المحتمل أنك واجهت رسالة الخطأ المخيفة هذه.

مُحبط، أليس كذلك؟ يظهر عادةً عندما يحاول عميلك إرسال أو استقبال بيانات من خادم، لكن الطلب يستغرق وقتًا طويلاً جدًا. بدلاً من الانتظار بصبر إلى الأبد، ينتهي وقت الخادم ويصدر هذا الخطأ. يغرق قلبك. يتلاشى شعور الانتصار على الفور، ويحل محله الخوف المألوف من تصحيح مشكلة في الإنتاج. ما الخطأ الذي حدث؟ تطبيقك يعمل، قاعدة البيانات متصلة بالإنترنت، فما المشكلة؟

إذا سئمت من لعب دور المحقق مع مهلات الاتصال وتريد أداة تمنحك رؤية واضحة تمامًا لطلبات واستجابات واجهة برمجة التطبيقات (API) الخاصة بك، فأنت بحاجة إلى التحقق من Apidog.

الآن، دعنا نكشف الستار ونزيل الغموض عن هذا الخطأ الشائع والمحبط. في هذا التعمق، سنتحدث عن ما يعنيه "مهلة طلب المنبع (upstream request timeout)" بالفعل، ولماذا يحدث، والأهم من ذلك، كيف يمكنك العثور عليه، وإصلاحه، ومنعه من إفساد يومك.

لنبدأ بالأساسيات: ماذا تعني "مهلة طلب المنبع (Upstream Request Timeout)"؟

دعنا نبسط الأمر.

عندما ترى "مهلة طلب المنبع"، فهذا يعني:

• حاول عميلك أو خادم الوكيل (مثل Nginx، أو بوابة API، أو موازن التحميل) إعادة توجيه طلب إلى خادم منبع (الخدمة الخلفية الحقيقية أو API).
• لكن خادم المنبع استغرق وقتًا طويلاً جدًا للاستجابة.
• بعد تجاوز حد معين، استسلم الوكيل وأرجع خطأ مهلة.

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

• التيار السفلي (Downstream): هذا هو الاتجاه نحو المستخدم النهائي أو العميل. عندما ترسل بيانات من خادمك إلى متصفح المستخدم، فإن تلك البيانات تنتقل باتجاه التيار السفلي.
• التيار العلوي (Upstream): هذا هو الاتجاه المعاكس بعيدًا عن المستخدم النهائي ونحو المصدر. عندما يحتاج خادم تطبيقك إلى طلب بيانات من خدمة أخرى (مثل قاعدة بيانات، أو بوابة دفع، أو واجهة برمجة تطبيقات داخلية أخرى)، فإنه يقوم بطلب باتجاه التيار العلوي.

لذا، في سياق تطبيق الويب:

• خادم تطبيقك (مثل Node.js، Python/Django، Java/Spring) هو باتجاه التيار السفلي من متصفح المستخدم.
• الخدمات التي يتحدث إليها خادم تطبيقك (مثل قاعدة بيانات MySQL، ذاكرة تخزين مؤقت Redis، واجهة برمجة تطبيقات الطقس لجهة خارجية) هي باتجاه التيار العلوي من خادم تطبيقك.

الخادم "العلوي" هو الخادم الذي تعتمد عليه لإكمال الطلب. خادمك هو عميل له.

فكر في الأمر على هذا النحو: تطلب طعامًا من نادل (خادم وكيل). يذهب النادل إلى المطبخ (خادم المنبع) وينتظر. ولكن إذا استغرق المطبخ وقتًا طويلاً جدًا لإعداد الطبق، يعود النادل في النهاية ويقول:

"آسف، المطبخ لم يستجب في الوقت المحدد."

هذا بالضبط ما تعنيه مهلة طلب المنبع في الشبكات وواجهات برمجة التطبيقات.

إذن، ما هي "مهلة طلب المنبع (Upstream Request Timeout)" بالضبط؟

الآن بعد أن عرفنا ما يعنيه "المنبع"، أصبح التعريف أكثر وضوحًا.

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

الأمر أشبه بإرسال بريد إلكتروني عاجل إلى زميل يطلب فيه معلومات بالغة الأهمية لإنهاء تقريرك. تنتظر وتنتظر، ولكن بعد 30 دقيقة، لم تتلق ردًا. لا يمكنك الانتظار أكثر من ذلك، لذلك يتعين عليك إرسال تقريرك إلى رئيسك غير مكتمل، مع ملاحظة تقول: "لم أتمكن من الحصول على المعلومات اللازمة من زميلي في الوقت المحدد." لقد مررت للتو بمهلة على المستوى البشري.

اللاعبون الرئيسيون في هذه الدراما

لرؤية هذا عمليًا، دعنا نحدد تدفق طلب ويب نموذجي:

1. المستخدم (العميل): متصفح الويب الخاص بك أو تطبيق الهاتف المحمول.
2. الوكيل العكسي/موازن التحميل (الحارس): غالبًا ما تكون هذه خدمة مثل Nginx، Apache، HAProxy، أو موازن تحميل مزود خدمة سحابية (AWS ALB، GCP CLB). وظيفته هي قبول الطلبات من الإنترنت وإعادة توجيهها إلى الخادم "الخلفي" أو "العلوي" الصحيح حيث يعيش رمز تطبيقك بالفعل.
3. خادم التطبيق (رمزك): هذا هو الخادم الذي يشغل رمز Python، Java، JavaScript، Ruby، وما إلى ذلك (مثل Gunicorn، Tomcat، بيئة تشغيل Node.js، Unicorn).
4. خدمات المنبع (المتخصصون): هذه هي الخدمات التي يستدعيها رمز تطبيقك، مثل:

• قواعد البيانات (MySQL، PostgreSQL، MongoDB)
• طبقات التخزين المؤقت (Redis، Memcached)
• الخدمات المصغرة الداخلية الأخرى (مثل "خدمة المستخدم" أو "خدمة الدفع")
• واجهات برمجة التطبيقات الخارجية لجهات خارجية (Stripe، Twilio، خرائط Google)

يحدث خطأ المهلة تحديدًا بين اللاعب 2 واللاعب 3. لقد قام الوكيل العكسي (Nginx) بإعادة توجيه الطلب إلى خادم التطبيق (تطبيق Node.js الخاص بك). ويبدأ مؤقتًا. إذا لم يرسل خادم تطبيقك استجابة كاملة إلى الوكيل العكسي قبل انتهاء صلاحية هذا المؤقت، فإن الوكيل العكسي يرفع يديه ويرسل خطأ 504 Gateway Timeout مرة أخرى إلى المستخدم.

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

الفرق بين مهلة البوابة (Gateway Timeout) ومهلة المنبع (Upstream Timeout)

غالبًا ما يخلط المطورون بين 504 Gateway Timeout وأخطاء مهلة المنبع. دعنا نوضح ذلك:

• مهلة البوابة (504) ← هذا يعني أن الوكيل أو البوابة (مثل Nginx، API Gateway، أو Cloudflare) لم يتلق استجابة في الوقت المحدد من خادم المنبع.
• مهلة طلب المنبع ← حالة أكثر تحديدًا حيث تخلى الوكيل صراحة عن الانتظار لخدمة المنبع.

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

لماذا يحدث هذا؟ المشتبه بهم المعتادون

مهلة المنبع هي عرض، وليست مرضًا. المرض دائمًا هو أن خادم تطبيقك يستغرق وقتًا طويلاً جدًا للاستجابة. دعنا نحقق في الأسباب الشائعة لذلك.

1. خادم التطبيق مرهق أو بطيء بالفعل

هذا هو السبب الأكثر وضوحًا. خادمك مشغول جدًا بحيث لا يستطيع التعامل مع الطلب في الوقت المناسب.

• استخدام عالي لوحدة المعالجة المركزية (CPU): قد يكون خادمك يعمل بنسبة 100% من وحدة المعالجة المركزية بسبب حساب معقد، أو رمز غير فعال، أو ببساطة الكثير من حركة المرور. إذا لم يتمكن من معالجة الطلبات بسرعة، تتأخر الاستجابات.
• استخدام عالي للذاكرة: إذا كان خادمك يقوم باستمرار بجمع البيانات المهملة أو تبديل الذاكرة إلى القرص، فإن كل شيء يتوقف.
• موارد غير كافية: ببساطة، قد تحتاج إلى خادم أكبر أو المزيد من مثيلات التطبيق. قد لا يتمكن خادمك الصغير الوحيد من التعامل مع تدفق الطلبات.

2. خدمات المنبع (التي يستدعيها خادم تطبيقك) بطيئة

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

• مشاكل قاعدة البيانات: هذا هو الجاني الأكبر.

1. الاستعلامات البطيئة: قد يؤدي فقدان فهرس قاعدة بيانات إلى تحويل استعلام يستغرق 10 مللي ثانية إلى فحص جدول كامل يستغرق 10 ثوانٍ.
2. أقفال قاعدة البيانات: قد تؤدي عملية كتابة طويلة الأمد إلى قفل الجداول، مما يمنع جميع طلبات القراءة اللاحقة.
3. استخدام عالي لوحدة المعالجة المركزية لقاعدة البيانات: قد يكون خادم قاعدة البيانات نفسه مرهقًا.

• استدعاءات API خارجية بطيئة: هل يستدعي تطبيقك خدمة طرف ثالث تمر بيوم سيء؟ إذا استغرقت واجهة برمجة تطبيقات تويتر 20 ثانية للاستجابة، فإن تطبيقك مجبر على الانتظار 20 ثانية قبل أن يتمكن من إكمال استجابته الخاصة.
• مشاكل الشبكة: قد يكون هناك زمن انتقال للشبكة أو فقدان حزم بين خادم تطبيقك وخادم قاعدة البيانات الخاص بك، خاصة إذا كانوا في مراكز بيانات أو مناطق توفر مختلفة.

3. إنها عملية طويلة الأمد (وهذا لا بأس به)

في بعض الأحيان، من المفترض أن يستغرق الطلب وقتًا طويلاً. يمكن أن يستغرق إنشاء تقرير معقد، أو معالجة ملف فيديو كبير، أو التعامل مع تصدير بيانات كبير دقائق، وليس مللي ثانية.

المشكلة هنا ليست أن العملية بطيئة؛ بل إننا نستخدم نمط الاتصال الخاطئ. لم يتم تصميم طلبات HTTP للاتصالات طويلة الأمد التي تستمر دقائق. فهي عرضة للانقطاع بسبب مشاكل الشبكة، وإغلاق المتصفحات، و... كما خمنت... مهلات.

سيناريوهات واقعية يحدث فيها هذا الخطأ

دعنا نجعل هذا مرتبطًا ببعض الأمثلة:

• الدفع في التجارة الإلكترونية ← ينقر المستخدم على "شراء"، لكن واجهة برمجة تطبيقات الدفع تستغرق وقتًا طويلاً.
• تطبيقات البث ← يفشل تشغيل الفيديو لأن شبكة CDN المنبع بطيئة.
• تكاملات API ← يستدعي تطبيقك واجهة برمجة تطبيقات لجهة خارجية، لكن خادمهم مثقل.
• الخدمات المصغرة (Microservices) ← تعتمد خدمة مصغرة على أخرى؛ إذا كانت إحداها بطيئة، فإن السلسلة بأكملها تنتهي بمهلة.

كما ترى، يظهر هذا الخطأ عبر الصناعات وحالات الاستخدام.

كيفية تصحيح مهلة طلب المنبع

حسنًا، يكفي نظرية. دعنا نصبح عمليين. ترى الخطأ في سجلاتك. ماذا تفعل بعد ذلك؟

الخطوة 1: تحقق من تكوين الوكيل العكسي الخاص بك

المكان الأول للبحث هو تكوين الوكيل العكسي الخاص بك (على سبيل المثال، Nginx). فهو يحدد حدود المهلة.

في Nginx، التوجيهات الرئيسية هي:

• proxy_read_timeout: الوقت بين عمليتي قراءة متتاليتين من خادم المنبع. الافتراضي غالبًا 60 ثانية.
• proxy_connect_timeout: الوقت اللازم لإنشاء اتصال بخادم المنبع. الافتراضي عادة 60 ثانية.
• proxy_send_timeout: الوقت بين عمليتي كتابة متتاليتين إلى خادم المنبع.

إذا تم تعيين proxy_read_timeout على 30 ثانية ويستغرق تطبيقك باستمرار 31 ثانية للاستجابة، فستحصل على خطأ 504 في كل مرة. معرفة هذه القيمة هي أول دليل لك.

الخطوة 2: تجهيز تطبيقك بالسجلات وأدوات مراقبة أداء التطبيق (APM)

تحتاج إلى معرفة أين يتم قضاء الوقت داخل تطبيقك.

• إضافة تسجيل مفصل: أضف سجلات في بداية ونهاية العمليات الرئيسية. "بدء استعلام المستخدم"، "تم الانتهاء من معالجة الدفع"، إلخ. سيساعدك هذا في تضييق نطاق نقطة النهاية أو الوظيفة البطيئة.
• استخدام أداة مراقبة أداء التطبيق (APM): أدوات مثل DataDog APM، New Relic، أو AppDynamics لا تقدر بثمن هنا. فهي تتتبع الطلبات تلقائيًا أثناء انتقالها عبر تطبيقك ويمكن أن تعرض لك تفصيلاً مفصلاً للوقت المستغرق:
• الوقت المستغرق في رمز تطبيقك نفسه.
• الوقت المستغرق في انتظار كل استعلام قاعدة بيانات.
• الوقت المستغرق في استدعاءات HTTP الخارجية لخدمات أخرى.

يمكن للوحة تحكم APM أن تخبرك على الفور: "آه، 95% من وقت الطلب يتم قضاؤه في استعلام SQL هذا!" أو "الاستدعاء إلى Stripe API يستغرق 25 ثانية!"

الخطوة 3: تحقق من خدمات المنبع الخاصة بك

بمجرد عزل الجزء البطيء، تحقق من خدمة المنبع.

• لقواعد البيانات: افحص سجلات الاستعلامات البطيئة. استخدم EXPLAIN (أو EXPLAIN ANALYZE) على الاستعلامات المشبوهة لمعرفة ما إذا كانت تفتقر إلى فهارس أو تقوم بعمليات فحص جدول كاملة.
• لواجهات برمجة التطبيقات الخارجية: تحقق من صفحات حالة تلك الخدمات (على سبيل المثال، status.stripe.com). قم بتجهيز استدعاءات HTTP الصادرة الخاصة بك بالتسجيل لتتبع أوقات استجابتها.
• للتخزين المؤقت: تحقق من نسبة الإصابة/الخطأ في التخزين المؤقت. تعني النسبة المنخفضة أن تطبيقك ينتقل إلى قاعدة البيانات الأساسية أكثر مما ينبغي، وهو أبطأ.

كيفية إصلاح ومنع مهلات المنبع

يعتمد إصلاح المشكلة على السبب الجذري الذي وجدته أثناء التصحيح.

الإصلاح 1: تحسين الكود والاستعلامات الخاصة بك

• تحسين قاعدة البيانات: هذا هو أسهل مكسب. أضف فهارس، أعد هيكلة الاستعلامات غير الفعالة، وفكر في استخدام ORM بحكمة (يمكنها أحيانًا إنشاء استعلامات غير فعالة جدًا).
• تحسين الكود: قم بتحليل رمز تطبيقك. هل تقوم بحلقات غير فعالة؟ معالجة مجموعات بيانات ضخمة في الذاكرة؟ استخدم التصفح، والتدفق، وخوارزميات أكثر كفاءة.
• تطبيق التخزين المؤقت: هذا مكسب هائل. استخدم Redis أو Memcached لتخزين نتائج العمليات المكلفة. في المرة التالية التي يتم فيها طلب نفس البيانات، يمكن تقديمها من ذاكرة التخزين المؤقت فائقة السرعة في مللي ثانية بدلاً من استعلام قاعدة البيانات البطيئة مرة أخرى.

الإصلاح 2: ضبط إعدادات المهلة (ولكن كن حذرًا!)

في بعض الأحيان، يكون الإصلاح الصحيح هو ببساطة زيادة المهلة في الوكيل العكسي الخاص بك. هذا مناسب إذا كنت قد أكدت أن العملية طويلة الأمد بطبيعتها ولا يمكن تحسينها بسهولة.

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

الإصلاح 3: استخدم النمط الصحيح للوظائف طويلة الأمد

للمهام التي تستغرق دقائق أو ساعات بشكل مشروع، لا تتعامل معها داخل دورة طلب/استجابة HTTP.

بدلاً من ذلك، استخدم نمطًا غير متزامن:

1. يؤدي طلب HTTP إلى إنشاء المهمة ووضعها في قائمة انتظار (مثل RabbitMQ، AWS SQS، أو Redis).
2. يستجيب التطبيق على الفور بحالة 202 Accepted ومعرف مهمة فريد (على سبيل المثال، {"status": "processing", "job_id": "abc123"}).
3. تقوم عملية عاملة خلفية منفصلة (أو دالة بدون خادم) بسحب المهام من قائمة الانتظار ومعالجتها.
4. يمكن للعميل لاحقًا استقصاء نقطة نهاية حالة منفصلة (على سبيل المثال، GET /jobs/abc123) للتحقق مما إذا كانت المهمة قد اكتملت والحصول على النتيجة.

هذا يحافظ على اتصالات HTTP قصيرة وسريعة ويمنع المهلات تمامًا للعمليات الطويلة.

الإصلاح 4: توسيع نطاق البنية التحتية الخاصة بك

إذا كانت المشكلة هي الحجم الخالص، فأنت بحاجة إلى التوسع.

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

كيف يمكن لـ Apidog مساعدتك في التغلب على شياطين المهلة

هنا تنتقل مجموعة أدوات API القوية من كونها شيئًا لطيفًا إلى جزء أساسي من سير عملك. Apidog هي منصة متكاملة مذهلة تجمع وظائف أدوات مثل Postman وSwagger وخوادم Mock في تجربة سلسة واحدة.

إليك كيف تساعد بشكل مباشر في مشاكل المهلة:

• اختبار الأداء الدقيق: يمكنك استخدام Apidog لبرمجة وتشغيل الطلبات مقابل واجهة برمجة التطبيقات الخاصة بك مع تتبع دقيق لوقت الاستجابة لكل استدعاء. يمكنك بسهولة إنشاء خط أساس للأداء ومعرفة على الفور ما إذا كان تغيير رمز جديد يتسبب في تراجع وزيادة في زمن الوصول.
• تصحيح الأخطاء بوضوح: عندما يفشل طلب، يمنحك Apidog صورة كاملة لدورة حياة الطلب والاستجابة بأكملها. يمكنك رؤية المدة التي استغرقتها كل خطوة بالضبط، مما يسهل تحديد ما إذا كان التأخير في مرحلة الاتصال، أو انتظار البايت الأول، أو تنزيل الاستجابة.
• التصميم من أجل المرونة: باستخدام Apidog لتصميم واجهات برمجة التطبيقات الخاصة بك وإنشاء نماذج أولية لها، يمكنك بناء أفضل الممارسات من البداية. يمكنك نمذجة النمط غير المتزامن الذي ناقشناه، مما يضمن أن مواصفات واجهة برمجة التطبيقات الخاصة بك تحدد بوضوح استجابات سريعة تبدأ وظائف الخلفية بدلاً من فرض عمليات طويلة الأمد في استدعاء متزامن.
• التعاون: شارك توثيق واجهة برمجة التطبيقات وحالات الاختبار الخاصة بك مع فريقك في Apidog. إذا كان مطور الواجهة الأمامية يواجه مهلات، فيمكنه التحقق بسرعة من السلوك المتوقع وحدود الأداء مباشرة في التوثيق المشترك، مما يزيل الارتباك.

يؤدي استخدام أداة مثل Apidog إلى تحويل تصحيح أخطاء المهلة من لعبة تخمين محبطة إلى تحقيق منظم قائم على البيانات.

الخاتمة: ترويض وحش المهلة

إذن، ماذا تعني "مهلة طلب المنبع"؟ في جوهرها، هي عندما ينتظر خادم وكيل وقتًا طويلاً جدًا لاستجابة من خدمة منبع وفي النهاية يستسلم؛ إنها صرخة استغاثة من بنيتك التحتية. إنها وكيلك العكسي يخبرك، "مرحبًا، لقد طلبت من تطبيقك إجابة، لكنه يستغرق وقتًا طويلاً جدًا، ولدي طلبات أخرى للتعامل معها!"

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

تذكر، الهدف ليس القضاء على المهلات تمامًا - هذا مستحيل. الهدف هو فهمها، والتعامل معها بلطف، وبناء أنظمة مرنة بما يكفي للتعامل مع الاستجابة البطيئة العرضية دون إفساد تجربة المستخدمين.

وإذا كانت واجهات برمجة التطبيقات جزءًا أساسيًا من مكدسك (وهو ما يحتمل أن يكون كذلك)، فلا تتركها دون فحص. ابدأ في مراقبتها اليوم باستخدام Apidog. إنه مصمم للمطورين والمختبرين الذين يرغبون في تصميم واختبار ومراقبة واجهات برمجة التطبيقات بسهولة، واتخاذ الخطوة الأولى في منع مهلات واجهة برمجة التطبيقات.

الآن انطلق، ولتكن استجاباتك سريعة ومهلاتك قليلة!