التغيير الأكثر فاعلية على الإطلاق لتحسين أداء البروكسي ليس شراء بروكسي أسرع؛ بل إعادة استخدام الاتصال القائم. فالعميل الذي يفتح اتصالًا جديدًا لكل طلب يدفع تكلفة إنشاء الاتصال باستمرار، وتتضاعف هذه التكلفة عند المرور عبر البروكسي.
التكلفة الحقيقية لإنشاء الاتصال
هذه الـ200 ms تُدفع من جديد مع كل اتصال جديد. فإن كنت ترسل 1,000 طلب وتفتح اتصالًا جديدًا في كل مرة، فستنفق 200 ثانية على الإعداد وحده.
كيف يعمل Keep-Alive؟
في HTTP/1.1 تكون الاتصالات دائمة افتراضيًا: فبعد وصول الاستجابة لا يُغلق الاتصال، ويُرسل الطلب التالي عبر المقبس نفسه. وهناك ثلاثة أشياء تُفسد هذا السلوك:
- الخادم
Connection: closeيرسل — يُغلق الاتصال. - ينشئ العميل كائن جلسة جديدًا مع كل طلب — فلا يعمل التجمّع إطلاقًا.
- تتجاوز مدة الخمول الحد — فيُسقِط البروكسي أو الخادم الاتصال.
إنشاء كائن Session, Client أو Agent جديد لكل طلب في الكود. وهذا يعطّل إعادة استخدام الاتصال تمامًا مهما كان إعداد التجمّع لديك.
الإعداد الصحيح
أبقِ حجم التجمّع أدنى قليلًا من حد التزامن لدى مزوّدك. فإن تجاوزته، تُنشأ اتصالات إضافية ثم تُغلق فورًا.
كم يبلغ المكسب؟
في القياس المثال، يخفض استخدام التجمّع الزمن الإجمالي إلى نحو الثلث. ويزداد المكسب كلما ارتفع زمن الاستجابة إلى البروكسي.
إعادة استخدام جلسة TLS
إلى جانب تجميع الاتصالات هناك مصدر كسب ثانٍ: تذكرة جلسة TLS. فعند إعادة الاتصال بالهدف نفسه يمكن تنفيذ مصافحة مختصرة بدلًا من المصافحة الكاملة. ومعظم العملاء الحديثين يفعلون ذلك تلقائيًا؛ المهم هو إعادة استخدام كائن العميل.
إذا أعدت إنشاء كائن العميل مع كل طلب فستُفقد تذكرة الجلسة وتُنفَّذ مصافحة كاملة في كل مرة.
توازن مدة الخمول
إبقاء الاتصال مفتوحًا لمدة طويلة جدًا قد يسبب مشكلة أيضًا: فقد يُسقط البروكسي أو الخادم الهدف الاتصال بصمت ولا يلاحظ عميلك ذلك إلا في الطلب التالي. وهذا يؤدي إلى نمط "الطلب الأول يفشل والثاني ينجح".
| الإعداد | المقترح | السبب |
|---|---|---|
| keepalive_expiry | 30–60 ثانية | ينبغي أن يكون أقصر من مهلة الخادم |
| حجم التجمّع | دون حد التزامن | الزائد مصافحة مهدورة |
| إعادة المحاولة | مرة واحدة | تعوّض الاتصال الساقط |
| حد عمر الاتصال | 5–10 دقائق | الاتصالات الطويلة العمر تصبح بائتة |
أبقِ مدة الخمول من مهلة الخادم أقصر . وبذلك تكون أنت من يغلق الاتصال، فلا تنشأ حالة "الخادم أغلق وأنا لا أعلم".
التعارض مع التدوير
تتعارض إعادة استخدام الاتصال مع تدوير IP بطبيعتها: فاستخدام الاتصال نفسه يعني البقاء على عنوان IP الخروج نفسه. وهذه ليست مشكلة، بل مسألة اختيار:
في معظم السيناريوهات يكون الخيار الثاني هو الصحيح: أعد استخدام الاتصال لفترة (30 طلبًا أو 5 دقائق مثلًا)، ثم جدّده.
لأجل استراتيجيات التدوير إلى مقالنا عن إعدادات التدوير يمكنك الاطّلاع.
الخلاصة
يمثل keep-alive وتجميع الاتصالات أكبر رافعة منفردة في أداء البروكسي. أنشئ كائن العميل مرة واحدة وأعد استخدامه، وأبقِ حجم التجمّع دون حد المزوّد، واضبط مدة الخمول لتكون أقصر من مهلة الخادم، وأضف محاولة إعادة واحدة. وإذا كانت هناك حاجة إلى التدوير ففضّل التجديد الدوري بدلًا من إغلاق التجمّع. وللقياس اختبار ping و فحص البروكسي يمكنك استخدام أدواتنا.