مهلة التنبؤ: هل الجواب الصحيح وصل قبل حاجته؟

الخلاصة السريعة

حدد بداية الساعة ونهاية الانتظار، ثم راجع صحة الجواب وتوقيته كلًا على حدة؛ الحساب السريع وحده لا يضمن وصول جواب مفيد في الموعد.

• لا يضع gRPC مهلة افتراضية؛ تجاوز الموعد المحدد يؤدي إلى DEADLINE_EXCEEDED لدى العميل في العقد الموثق. ^[1]
• في خطنا المتتابع 20 + 30 + 40 + 20 = 110 مللي ثانية من البداية إلى الوصول؛ زمن النموذج 40 وحده لا يحقق حد 100.
• نقبل التوقيت عند الوصول خلال 100 مللي ثانية شاملًا الحد؛ جواب صحيح عند 110 متأخر، وجواب خاطئ عند 80 يحقق التوقيت فقط.
• تطبيق الخادم مسؤول عن إيقاف الأنشطة التي أنشأها لخدمة الاتصال؛ انتهاء انتظار العميل لا يثبت توقف كل العمل أو سبب التأخر. ^[1]

أعلن الموعد بدل افتراضه

في gRPC لا توجد مهلة افتراضية، ويترك غيابها احتمال انتظار طويل جدًا. تصف الوثائق فشل الاتصال لدى العميل بحالة DEADLINE_EXCEEDED عند تجاوز الموعد المحدد. ^[1]

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

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

احسب الطريق إلى الجواب كاملًا

نفترض أربع مراحل متتابعة لا تتداخل: تجهيز المدخل يستغرق 20 مللي ثانية، وانتظار الدور 30، وحساب النموذج 40، وعودة الجواب 20. نبدأ عند صفر، فينتهي التجهيز عند 20، والانتظار عند 50، والحساب عند 90، والوصول عند 110.

مجموع المراحل 110 مللي ثانية. لو عرضت لوحة زمن النموذج وحده لكتبت 40، وهو صحيح لتلك المرحلة المفترضة، لكنه لا يساوي الزمن الذي انتظره العميل في تعريفنا. اختيار جزء من الطريق يغير السؤال الذي يجيب عنه الرقم.

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

افصل صحة الجواب عن قبوله الزمني

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

جواب يطابق المرجع عند 110 صحيح وفق المرجع، لكنه يصل بعد حد التوقيت. جواب مختلف عن المرجع عند 80 يصل في الموعد، لكنه لا يحقق شرط الصحة. هذان محوران منفصلان؛ لا تكفي سرعة الوصول لتغيير حكم المقارنة.

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

ماذا يحدث بعد انتهاء الانتظار؟

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

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

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