زمن الاستجابة الذي تشعر به فعلاً

يضغط العميل «أرسل الرمز»، وينتظر، ويضغط مجدداً، ثم يستسلم قبل أن يصل أي من الرمزين. ولوحة واجهتك البرمجية تقول إن المزوّد أجاب خلال 120 جزءاً من الثانية. وكلاهما صحيح: فالجزء الذي تقيسه أصغر أجزاء الانتظار. وزمن الاستجابة في الاتصالات نوعان مختلفان جداً — ثوانٍ لتصل رسالة إلى هاتف، وأجزاء من الثانية لتبدو مكالمة مباشرة طبيعية — وفي الحالتين يحدد المساراتُ والتصميمُ معظمَ الزمن الذي يشعر به الناس، لا شيفرتك. يتناول هذا المقال أين يذهب الوقت، وماذا تقيس، وكيف تصمّم للحالة البطيئة.

بالنسبة لرمز التحقق — أكثر الرسائل حساسية للزمن في معظم الأنشطة — لا تشبه الميزانية ما يتوقعه الناس:

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

1. قِس من طرف إلى طرف. توقيت عند قرارك الإرسال، وآخر عند وصول إيصال التسليم. وهذا هو الرقم الذي يعيشه العميل.
2. راقب الذيل لا المتوسط. لا أحد يعيش المتوسط. فالمئينان الخامس والتسعون والتاسع والتسعون هما ما يسمع عنه فريق الدعم؛ ومتوسط ثانيتين يخفي عادةً ذيلاً بعشرات الثواني.
3. قسّم حسب البلد والساعة. مشكلات الزمن محلية. والرقم العالمي يخفي السوق المعطّل بعد ظهر الثلاثاء.
4. اختر المسار. الربط المباشر بالمشغّلين داخل السوق يتفوق عادةً على أي تحسين فوقه. وهذا قرار شراء يبدو كقرار هندسي.
5. أنجز العمل البطيء مبكراً. ينبغي أن تكون حالة الموافقة واعتماد القالب واختيار المسار جاهزة قبل الإرسال؛ وألا يكون مسار الإرسال أول موضع يظهر فيه فقد ذاكرة مؤقتة.
6. أرسل قبل أن تحتاج. لكل ما يمكن توقعه — تذكير أو إشعار مجدول — تبدأ الميزانية حين تقرر، لا حين ينتظر المستخدم.

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

وإعادة المحاولة على المسار الذي فشل للتو محاولة ثانية للفشل: تزيد الحمل على مسار متعثر وتؤخر المستخدم أكثر. أعِد المحاولة على مسار آخر أو قناة أخرى، أو أخبر المستخدم بدلاً من ذلك — وتوقف بعد عدد قليل من المحاولات. فالأنظمة بلا سقف تُنتج نمط يوم الانقطاع حيث يعيد الجميع المحاولة ولا يمر شيء.

في المكالمات، المرجع هو توصية ITU-T G.114 بشأن تأخير الإرسال في اتجاه واحد: حتى نحو 150 جزءاً من الثانية مقبول لمعظم المحادثات؛ وبين 150 و400 قابل للاستخدام لكنه ملحوظ؛ وما فوق 400 غير مقبول لتخطيط المحادثة العادية. وعملياً:

• المسافة مهمة. الوسائط المرحَّلة عبر خادم في قارة أخرى قد تستهلك معظم هذه الميزانية قبل أي معالجة. فاسأل أين خوادم الوسائط، لا أين مقر الشركة فقط.
• التذبذب وفقد الحزم يُحسّان كتأخير. المخازن المؤقتة التي تمتص التذبذب تضيف تأخيراً، والحزم المفقودة تسبب فجوات. وجودة الشبكة أهم من سعتها الخام.
• الترحيل شائع. حتى مكالمات WebRTC «من طرف إلى طرف» تلجأ إلى خادم ترحيل (TURN) حين يتعذر مسار مباشر، وكثيراً ما يحدث ذلك على شبكات الشركات والهواتف المحمولة.

تطبيق تقنية مالية تلقّى شكاوى عن رموز الدخول في بلد واحد فقط.

• القياس من طرف إلى طرف أظهر وسيطاً قدره 4 ثوانٍ هناك، لكن المئين الخامس والتسعين بلغ 38 ثانية بين السادسة والعاشرة مساءً؛ وبقيت الدول الأخرى دون 10 ثوانٍ.
• السبب مسار شريك فيه محطة مجمّع تزدحم مساءً.
• التغييرات: مسار مباشر لذلك البلد من مزوّد ثانٍ؛ ورفع صلاحية الرمز من 60 إلى 180 ثانية؛ وخيار «أرسل بمكالمة صوتية» يظهر عند 15 ثانية؛ وإعادة إرسال واحدة مسموحة على المسار الآخر.
• النتيجة: انخفض المئين الخامس والتسعون إلى 9 ثوانٍ، وتراجع فشل الدخول في ذلك البلد بشدة. ولم يتغير سطر واحد في منطق توليد الرموز.

• ما وسيط زمن التسليم والمئين الخامس والتسعون لكل بلد، مقيساً حتى إيصال التسليم — لا حتى قبول الواجهة؟
• أي الدول تصلونها مباشرة، وأيها عبر شركاء؟
• ماذا يعني إيصال «مُسلَّم» في كل بلد، وكم قد يتأخر وصوله؟
• في الصوت والفيديو، أين خوادم الوسائط والترحيل لديكم، وهل أستطيع اختيار المنطقة؟

التالي في هذا المسار: متى ينتمي الفيديو إلى الدعم. ولتضمين التزامات زمن التسليم في الاتفاقية، اقرأ تقييم عقد CPaaS؛ ولكيفية عمل الوسائط المباشرة من الداخل، انظر WebRTC بلغة بسيطة.