أفضل الممارسات لطلبات عرض الأسعار في الوقت الفعلي (RTB)

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

إدارة عمليات الربط

إبقاء الاتصالات نشطة

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

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

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

تجنُّب إغلاق الروابط

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

• مهلة وضع عدم النشاط إلى 2.5 دقيقة
• الحد الأقصى لعدد الطلبات على اتصال بأعلى قيمة ممكنة.
• الحد الأقصى لعدد الاتصالات بأعلى قيمة يمكن أن تستوعبها ذاكرة الوصول العشوائي الخاصة بك، مع الحرص على التحقق من أنّ عدد الاتصالات لا يقارب هذه القيمة أكثر من اللازم.

في Apache، على سبيل المثال، يستلزم هذا ضبط KeepAliveTimeout على 150، وMaxKeepAliveRequests على صفر، وMaxClients على قيمة تعتمد على نوع الخادم.

وبعد ضبط سلوك الاتصال، عليك أيضًا التأكّد من أنّ رمز مقدّم عروض الأسعار لا يغلق الاتصالات بدون داعٍ. على سبيل المثال، إذا كان لديك رمز واجهة أمامية يعرض استجابة افتراضية "بلا عرض أسعار" في حالة حدوث أخطاء في الخلفية أو انتهاء المهلة، تأكد من أن الرمز يعرض استجابته بدون إغلاق الاتصال. بهذه الطريقة، تتجنب الموقف الذي يؤدي إلى زيادة الحمل على مقدِّم عرض السعر، ويبدأ في إنهاء الاتصالات، ويزداد عدد المهلات، ما يؤدي إلى السيطرة على مقدِّم عرض السعر.

الحفاظ على توازن الاتصالات

في حال اتصل "الشراة المعتمَدون" بخوادم مقدّم عرض السعر من خلال خادم وكيل، قد تصبح الاتصالات غير متوازنة بمرور الوقت، لأنّ "الشراة المعتمَدون" لا يمكنهم تحديد خادم نظام عروض الأسعار الذي يتلقّى كل طلب شرح، لأنّه لا يعرف سوى عنوان IP للخادم الوكيل. بمرور الوقت، وعندما ينشئ "الشراة المعتمَدون" عمليات الربط ويغلقها وتعيد تشغيل خوادم مقدّم عرض السعر، يمكن أن يتغيّر عدد الاتصالات المرتبطة بكل منها بشكل كبير.

عندما يتم استخدام بعض الاتصالات بكثرة، قد تظل الاتصالات الأخرى المفتوحة غير نشطة في الغالب لأنها ليست مطلوبة في ذلك الوقت. مع تغيُّر عدد الزيارات لدى "الشراة المعتمَدون"، يمكن أن تصبح الاتصالات غير النشطة مفعَّلة ويمكن أن تصبح الاتصالات النشطة غير نشِطة. قد يؤدي ذلك إلى حدوث حِمل غير متساوي على خوادم نظام عروض الأسعار في حال تجميع الاتصالات بشكل سيئ. وتحاول Google منع حدوث ذلك عن طريق إغلاق جميع الاتصالات بعد 10,000 طلب، لإعادة موازنة الاتصالات السريعة تلقائيًا بمرور الوقت. إذا كنت لا تزال غير متوازنة عدد الزيارات في بيئتك، هناك خطوات إضافية يمكنك اتخاذها:

1. حدد الواجهة الخلفية لكل طلب بدلاً من مرة واحدة لكل اتصال إذا كنت تستخدم خوادم وكيلة للواجهة الأمامية.
2. حدِّد حدًا أقصى لعدد الطلبات لكل اتصال إذا كنت تستخدم خادم وكيل لموازنة حمل الأجهزة أو جدار حماية، وتم إصلاح عملية الربط بعد إنشاء الاتصالات. تجدر الإشارة إلى أنّ Google تحدّد حاليًا حدًا أقصى يبلغ 10,000 طلب لكل اتصال، لذلك لن تحتاج إلى تقديم قيمة أكثر صرامة إلا إذا كنت لا تزال تجميع الروابط الساخنة في بيئتك. في خادم Apache، على سبيل المثال، يمكنك ضبط MaxKeepAliveRequests على 5,000.
3. يمكنك ضبط خوادم مقدِّم عرض السعر لمراقبة معدّلات الطلبات وإغلاق بعض الاتصالات الخاصة به إذا كانت تعالج عددًا كبيرًا جدًا من الطلبات مقارنةً بالتطبيقات المشابهة.

التعامل مع الحمل الزائد بسلاسة

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

لاستيعاب التغيّرات المؤقتة في حركة المرور (تصل إلى أسبوع واحد) بين المناطق (خاصةً بين آسيا وغرب الولايات المتحدة وغرب الولايات المتحدة وشرق الولايات المتحدة)، ننصح بنسبة 15% من نسبة التغيُّر بين 7 أيام الذروة خلال 7 أيام وQPS لكل موقع تجارة.

من حيث السلوك في ظل الأعباء الثقيلة، يندرج مقدّمو عروض الأسعار ضمن ثلاث فئات واسعة:

نظام عرض الأسعار "الاستجابة لكل شيء"

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

• ومع ارتفاع معدّل الطلبات، يرتفع وقت الاستجابة إلى أن تنتهي مهلة جميع الطلبات
• ترتفع أوقات الاستجابة بشكل كبير مع اقتراب معدلات وسائل الشرح من الذروة
• يبدأ تقييد المحتوى، ما يقلّل بشكل كبير من عدد وسائل الشرح المسموح به.
• تبدأ أوقات الاستجابة في التعافي، ما يؤدي إلى تقليل التقييد
• تبدأ الدورة مرة أخرى.

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

عرض السعر "خطأ في التحميل الزائد"

يقبل نظام عرض السعر هذا طلبات عروض الأسعار بما يصل إلى معدّل معيّن، ثم يبدأ في عرض أخطاء لبعض وسائل الشرح. ويمكن أن يتم ذلك من خلال المهلات الداخلية أو إيقاف إضافة قائمة الاتصال إلى "قائمة المحتوى التالي" (التي يتم التحكّم فيها من خلال ListenBackLog على Apache) أو تنفيذ وضع احتمالية لاحتمالية إنقاص المحتوى عند زيادة معدّل الاستخدام أو أوقات الاستجابة أو بعض الآليات الأخرى. إذا لاحظت Google معدّل خطأ أعلى من %15، سنبدأ في التقييد. على عكس نظام عرض الأسعار "الاستجابة لكل شيء"، يخفّض مقدِّم عرض الأسعار هذا الخسائر، ما يتيح له استرداد قيمة عرض الأسعار فورًا عند انخفاض معدّلات الطلب.

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

نظام عروض الأسعار "بدون عرض أسعار على الحمل الزائد"

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

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

ننصح بدمج النهج "خطأ عند التحميل الزائد" مع النهج "بدون عرض أسعار عند تحميل زائد" على النحو التالي:

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

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

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

الرد على الإشعارات

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

Google

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

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

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

ننصحك باستخدام تبادل المعلومات بين الشبكات.

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

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

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

إرسال نظام أسماء نطاقات ثابت

ننصح المشترين دائمًا بإرسال نتيجة واحدة ثابتة لنظام أسماء النطاقات إلى Google والاعتماد على Google لمعالجة تسليم الزيارات.

في ما يلي ممارستان شائعتان من خوادم نظام أسماء النطاقات لدى مقدِّمي عروض الأسعار عند محاولة تحميل الرصيد أو إدارة مدى التوفّر:

1. يوزّع خادم نظام أسماء النطاقات عنوانًا واحدًا أو مجموعة فرعية من العناوين استجابةً لطلب بحث، ثم يبدّل بين نتائج هذه الاستجابة بطريقة معيّنة.
2. يستجيب خادم نظام أسماء النطاقات دائمًا باستخدام مجموعة العناوين نفسها، ولكنه يبدّل ترتيب العناوين في الاستجابة.

الأسلوب الأول ضعيف في موازنة التحميل نظرًا لوجود الكثير من التخزين المؤقت على مستويات متعددة من الحزمة، ومن المحتمل ألا تحصل محاولات تجاوز التخزين المؤقت على النتائج المفضلة أيضًا نظرًا لأن Google تفرض وقت حل نظام أسماء النطاقات على مقدّم عرض الأسعار.

إنّ الأسلوب الثاني لا يحقق توازن التحميل على الإطلاق، لأنّ محرّك بحث Google يختار بشكل عشوائي عنوان IP من قائمة استجابة نظام أسماء النطاقات، وبالتالي لا يهم الترتيب في الاستجابة.

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