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

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

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

الحفاظ على ربط الأجهزة

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

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

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

تجنب إغلاق الاتصالات

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

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

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

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

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

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

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

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

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

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

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

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

مقدّم عروض الأسعار "الردّ على كلّ الطلبات"

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

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

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

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

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

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

"عدم تحديد عروض أسعار عند الحمل الزائد" مقدِّم عرض سعر

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

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

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

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

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

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

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

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

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

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

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

تبادل المعلومات بين الشبكات

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

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

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

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

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

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

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

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

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

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