اختبار Mobile Proxy لدقيقة واحدة لا يقول الكثير عن جلسة تستمر ساعتين. الشبكة الخلوية تتأثر بالتغطية والازدحام وتغيير البرج وسياسة المشغل والمزود. لذلك تحتاج Soak test يسجل الزمن والعنوان وال latency والأخطاء، ويربط كل تغير بما حدث للجلسة داخل المتصفح. الهدف معرفة هل ال ـproxy مناسب لتدفقك الطويل، لا إثبات أنه يملك أفضل speed في لحظة معينة.
حدد سيناريو الجلسة قبل القياس
اختر نفس الموقع أو مجموعة المواقع التي تستخدمها، وحدد إن كانت هناك WebSocket أو upload أو navigation متكرر. شغل Profile بنفس device config والبروكسي نفسه. سجل public IP و ASN و DNS ووقت البداية. لا تغير إعدادات أخرى أثناء الاختبار حتى تعرف أثر الشبكة وحدها.
اجمع عينات زمنية وليس متوسطًا واحدًا
كل دقيقة أو خمس دقائق نفذ طلبًا صغيرًا وسجل latency و status و IP. احتفظ ب ـP50/P95 وعدد timeouts وفترات الانقطاع. إذا تغير IP، سجل اللحظة وما إذا كانت connections الجارية انقطعت. المتوسط يخفي دقيقة كاملة من الفشل إذا بقية الساعة سريعة.
خطوات عملية
- سجل baseline.
- نفذ probe دوريًا.
- احفظ IP/latency/status.
- راقب WebSocket إن وجد.
- علم أحداث rotation/reconnect على timeline.
اختبر rotation بطريقة متعمدة
إذا يوفر المزود endpoint أو session parameter للتدوير، نفذه في نقطة معروفة بدل انتظار حدث عشوائي. تحقق من سرعة حصول IP جديد وهل البلد/ASN بقي ضمن المطلوب. ثم شاهد أثره على الجلسة. لا تنفذ rotation أثناء خطوة غير قابلة للاستعادة في الإنتاج إلا لو أثبت الاختبار أنها تتحمل ذلك.
قائمة مراجعة
- rotation trigger معروف.
- زمن الحصول على IP جديد مقاس.
- الاتصالات القديمة تتعامل مع التغيير بصورة مفهومة.
- Retry لا يكرر submit/transaction.
- Session ID لا يُعاد استخدامه بين Profiles بالخطأ.
قارن 4 G و 5 G على نفس المعيار
لا تفترض أن 5 G دائمًا أكثر ثباتًا؛ التغطية والازدحام والمسار أهم. قارن success rate و P95 latency والانقطاعات في نفس المكان/المزود قدر الإمكان. لو الشبكة تنتقل تلقائيًا بين الجيلين، سجل الحدث بدل معاملته كحالتين منفصلتين تمامًا.
حدد SLO للجلسة
قرر قبل الشراء ما المقبول: مثل 99% نجاح probes، P95 أقل من حد معين، وعدم وجود أكثر من انقطاع طويل لكل ساعة. قارن المزود بهذه الأهداف. Proxy لا يحقق SLO المطلوب لا يصبح مناسبًا فقط لأن سعره أقل أو speed test أعلى.
قائمة مراجعة
- SLO مكتوبة.
- فترة الاختبار كافية.
- عدة جلسات مختبرة.
- النتائج محفوظة للمقارنة.
- التكلفة مرتبطة بالجودة الفعلية.
اختبر الاستعادة بعد انقطاع فعلي
الثبات لا يعني غياب الانقطاع فقط؛ يعني أن التطبيق يعرف ماذا يفعل عندما يحدث. افصل الاتصال لثوانٍ أو نفذ reconnect متعمدًا، ثم راقب هل WebSocket تعاد، وهل الصفحة تحتاج reload، وهل ال ـIP الجديد يغير سياق المهمة. في الأتمتة، احفظ checkpoint قبل الاختبار وتأكد أن retry لا يعيد إرسال نموذج أو عملية مالية سبق تنفيذها. هذه التجربة تقيس جودة الاستعادة، وهي جزء أساسي من جلسة طويلة ناجحة.
قائمة مراجعة
- الانقطاع المتعمد مسجل.
- زمن الاستعادة مقاس.
- حالة الصفحة بعد reconnect معروفة.
- الأثر الخارجي لا يتكرر.
- الجلسة تعرف متى تحتاج تدخلًا يدويًا.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…