أفضل الممارسات لطلبات عرض الأسعار في الوقت الفعلي (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%، سنبدأ في تقييد البيانات بخلاف "الاستجابة لكل شيء" مقدِّم عرض سعر، ومقدِّم عرض سعر هذا "يخفض خسائره"، وهو ما يتيح استرداد البيانات فورًا عند انخفاض أسعار الطلبات إلى الأسفل.

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

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

يقبل نظام عرض السعر هذا وسائل الشرح بما يصل إلى سعر معيّن، ثم يبدأ في عرض "بدون عرض سعر" الردود لأي حمل زائد. يشبه الخطأ "خطأ عند التحميل الزائد" مقدِّم عرض سعر يمكن تنفيذ ذلك بعدة طرق. ما يختلف هنا هو أنه لا إلى 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

"id": "4YB27BCXimH5g7wB39nd3t"

id: "7xd2P2M7K32d7F7Y50p631"

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

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

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

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

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

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

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

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

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

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

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

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