يشرح هذا الدليل أفضل الممارسات التي يجب مراعاتها عند تطوير التطبيقات وفقًا لبروتوكول RTB.
إدارة عمليات الربط
الحفاظ على اتصالاتك
يؤدي إنشاء اتصال جديد إلى زيادة أوقات الاستجابة ويستغرق موارد أكثر بكثير على كلا الطرفَين مقارنةً بإعادة استخدام اتصال حالي. من خلال إغلاق عدد أقل من الاتصالات، يمكنك تقليل عدد الاتصالات التي يجب فتحها مجددًا.
أولاً، يتطلّب كل اتصال جديد رحلة ذهاب وإياب إضافية على الشبكة لتأسيسه. بما أنّنا نُنشئ اتصالات عند الطلب، يكون للمطلوب الأول في الاتصال مهلة فعّالة أقصر ومن المرجّح أن تنتهي مهلته قبل الطلبات اللاحقة. تؤدي أي مهلات إضافية إلى زيادة معدّل الأخطاء، ما قد يؤدي بدوره إلى تقييد عروض أسعارك.
ثانيًا، تنشئ العديد من خوادم الويب سلسلة مهام عامل مخصّصة لكل اتصال يتم إجراؤه. وهذا يعني أنّه لإغلاق الاتصال وإعادة إنشائه، يجب على الخادم إيقاف مؤشر تسلسل ورفضه، وتخصيص مؤشر تسلسل جديد، وجعله قابلاً للتنفيذ، و إنشاء حالة الاتصال، قبل معالجة الطلب أخيرًا. وهذا يتطلّب الكثير من الجهد غير الضروري.
تجنُّب إغلاق الاتصالات
ابدأ بضبط سلوك الاتصال. تم تصميم معظم الإعدادات التلقائية للخادم خصيصًا للاستخدام في البيئات التي تتضمّن أعدادًا كبيرة من العملاء، حيث يقدّم كل عميل عددًا صغيرًا من الطلبات. في المقابل، بالنسبة إلى عروض الإعلانات الديناميكية، ترسل مجموعة صغيرة من الأجهزة الطلبات بالنيابة عن عدد كبير من المتصفّحات، نسبيًا. في ظل هذه الظروف، من المنطقي إعادة استخدام عمليات الربط أكبر عدد ممكن من المرات. ننصحك بضبط ما يلي:
- مهلة وضع عدم النشاط إلى 2.5 دقيقة
- الحد الأقصى لعدد الطلبات في اتصال إلى أعلى قيمة ممكنة
- الحد الأقصى لعدد عمليات الاتصال بأعلى قيمة يمكن أن تستوعبها ذاكرة الوصول العشوائي ، مع الحرص على التأكّد من أنّ عدد عمليات الاتصال لا يقترب من هذه القيمة كثيرًا.
في Apache، على سبيل المثال، سيتضمّن ذلك ضبط
KeepAliveTimeout على 150 وMaxKeepAliveRequests على
صفر وMaxClients على قيمة تعتمد على نوع الخادم.
بعد ضبط سلوك الاتصال، يجب أيضًا التأكّد من أنّ رمز مقدم عروض الأسعار لا يغلق الاتصالات بدون داعٍ. على سبيل المثال، إذا كان لديك رمز برمجي في واجهة العميل يعرض تلقائيًا استجابة "لا تتوفّر عروض أسعار" في حال حدوث أخطاء في واجهة العميل أو انتهاء مهلة، تأكَّد من أنّ الرمز يعرض استجابته بدون إغلاق الربط. بهذه الطريقة، يمكنك تجنُّب الموقف الذي يصبح فيه مقدّم عروض الأسعار مشغولاً بشكلٍ مفرط، ويبدأ الاتصال بالإغلاق، ويزداد عدد حالات انتهاء مهلة الاتصال، ما يؤدي إلى خفض معدّل إرسال عروض أسعاره.
الحفاظ على توازن عمليات الربط
إذا تواصلت "المشترون المعتمَدون" مع خوادم مقدّم عروض الأسعار من خلال خادم وكيل، قد تصبح عمليات الاتصال غير متوازنة بمرور الوقت لأنّ "المشترين المعتمَدين" لا يمكنهم تحديد خادم مقدّم عروض الأسعار الذي يتلقّى كل طلب مساعدة، وذلك لأنّهم يعرفون عنوان IP الخاص بخادم الوكيل فقط. بمرور الوقت، عندما يُنشئ "المشترون المعتمَدون" اتصالات ويغلقونها ويُعيد تشغيل خوادم مقدّمي عروض الأسعار، يمكن أن يصبح عدد الاتصالات المُحدَّدة لكلٍّ منها متغيّرًا للغاية.
عندما يتم استخدام بعض الاتصالات بشكل كبير، قد تظل الاتصالات المفتوحة الأخرى غير نشطة في معظم الأحيان لأنّها غير مطلوبة في الوقت الحالي. مع تغيُّر زيارات "المشترين المعتمَدين"، يمكن أن تصبح عمليات الربط غير النشطة نشطة ويمكن أن تصبح عمليات الربط النشطة غير نشطة. وقد تؤدي هذه العوامل إلى حدوث أحمال غير متساوية على خوادم عروض الأسعار إذا كانت عمليات الربط مجمّعة بشكلٍ سيئ. تحاول Google منع حدوث ذلك من خلال إغلاق جميع عمليات الربط بعد 10,000 طلب، لإعادة التوازن تلقائيًا بين عمليات الربط التي تشهد ازديادًا في عدد الطلبات بمرور الوقت. إذا استمرت زيارات موقعك الإلكتروني في عدم التوازن في البيئة، يمكنك اتّخاذ خطوات إضافية:
- اختَر الخلفية لكل طلب بدلاً من مرة واحدة لكل اتصال إذا كنت تستخدم وكلاء واجهة برمجة التطبيقات.
- حدِّد الحد الأقصى لعدد الطلبات لكل اتصال إذا كنت
توفّر اتصالات وكيلة من خلال أداة موازنة تحميل الأجهزة أو جدار الحماية، ويكون الربط
ثابتًا بعد إنشاء الاتصالات. تجدر الإشارة إلى أنّ Google تحديدًا
تضع حدًا أقصى يبلغ 10,000 طلب لكل اتصال، لذلك
لن تحتاج إلى تقديم قيمة أكثر صرامة إلا إذا استمرت عمليات الربط
المزدحمة في تجميعها في بيئتك. في Apache، على سبيل المثال،
اضبط
MaxKeepAliveRequestsعلى 5,000. - يمكنك ضبط خوادم مقدّم عروض الأسعار لتتبُّع معدّلات الطلبات وإغلاق بعض اتصالاته إذا كان يعالج باستمرار عددًا كبيرًا جدًا من الطلبات مقارنةً بنظرائه.
التعامل مع الحمل الزائد بسلاسة
من الأفضل ضبط الحصص على مستوى عالٍ بما يكفي ليتمكّن نظام عروض الأسعار من تلقّي كل الطلبات التي يمكنه معالجتها، ولكن ليس أكثر من ذلك. من الناحية العملية، إنّ الحفاظ على الحصص عند المستويات المثلى هو مهمة صعبة، ويحدث الحمل الزائد لأسباب متنوعة: إيقاف الخدمة في الخلفية خلال أوقات الذروة، أو تغيير مزيج الزيارات بحيث يتطلب مزيدًا من المعالجة لكل طلب، أو ضبط قيمة الحصة على قيمة عالية جدًا. وبالتالي، من المفيد التفكير في سلوك مقدّم عروض الأسعار عند تلقّي عدد كبير جدًا من الزيارات.
لاستيعاب التغيُّرات المؤقتة في عدد الزيارات (لمدة تصل إلى أسبوع) بين المناطق (خاصةً بين آسيا والولايات المتحدة الغربية والشرق والغرب)، ننصح بترك هامش 15% بين ذروة 7 أيام وعدد طلبات البحث في الثانية لكل موقع جغرافي للتداول.
من حيث السلوك في ظلّ الأحمال الثقيلة، تندرج عروض الأسعار ضمن ثلاث فئات عامة:
- مقدّم عروض الأسعار "الردّ على كلّ الطلبات"
على الرغم من أنّه من السهل تنفيذ هذا المقدّم لعروض الأسعار، إلا أنّه يحقّق الأداء الأسوأ عند ازدحامه. ويحاول ببساطة الردّ على كلّ طلب عروض أسعار وارد، بغض النظر عن محتوى الطلب، مع إضافة أيّ طلب لا يمكن عرضه على الفور إلى "قائمة الانتظار". غالبًا ما يكون السيناريو الذي يلي ذلك على النحو التالي:
- ومع ارتفاع معدّل الطلبات، تزداد أوقات استجابة الطلبات، إلى أن تبدأ مهلة جميع الطلبات في الانتهاء.
- ارتفاع أوقات الاستجابة بشكل كبير مع اقتراب معدّلات وسائل الشرح من الذروة
- يبدأ الحدّ من السرعة، ما يؤدي إلى انخفاض حاد في عدد الرسومات التوضيحية المسموح بها.
- تبدأ أوقات الاستجابة في العودة إلى وضعها الطبيعي، ما يؤدي إلى تقليل الحدّ الأقصى للسرعة
- تبدأ الدورة من جديد.
يشبه الرسم البياني لوقت الاستجابة لمقدّم عروض الأسعار هذا نمطًا حادًا جدًا من أسنان المنشار. بدلاً من ذلك، تؤدي الطلبات التي تم وضعها في قائمة الانتظار إلى بدء الخادم في نقل صفحات الذاكرة أو تنفيذ إجراء آخر يؤدي إلى إبطاء الأداء على المدى الطويل، ولا يتم أبدًا معالجة أوقات الاستجابة الطويلة إلى أن تنتهي أوقات الذروة، ما يؤدي إلى انخفاض معدلات الطلبات خلال فترة الذروة بأكملها. وفي كلتا الحالتَين، يتم إجراء عدد أقل من الطلبات أو الاستجابة لها مقارنةً بما لو تم ضبط الحصة على قيمة أقل.
- مقدّم عروض الأسعار "خطأ في حالة التحميل الزائد"
يقبل مقدّم عروض الأسعار هذا المقاطع التوضيحية بمعدّل معيّن، ثم يبدأ في عرض أخطاء في بعض المقاطع التوضيحية. ويمكن إجراء ذلك من خلال مهلات داخلية أو إيقاف ميزة "قائمة الانتظار للاتصال" (التي يتحكّم فيها
ListenBackLogعلى Apache) أو تنفيذ وضع إسقاط عشوائي عند ارتفاع معدّل الاستخدام أو وقت الاستجابة بشكلٍ مفرط أو من خلال آلية أخرى. إذا رصدت Google نسبة أخطاء تزيد عن %15، سنبدأ في الحد من عدد عمليات التحميل. على عكس مقدّم عروض الأسعار الذي "يردّ على كل الطلبات"، يحدّد مقدّم عروض الأسعار هذا "خسائره"، ما يتيح له التعافي على الفور عندما تنخفض معدّلات الطلبات.يشبه الرسم البياني لوقت الاستجابة لمقدّم عروض الأسعار هذا نمطًا ضحلًا من أسنان المنشار أثناء حالات التحميل الزائد، ويتم تحديده بالقرب من الحد الأقصى المقبول للمعدّل.
- مقدّم عروض الأسعار "بدون عرض سعر عند التحميل الزائد"
يقبل مقدّم عروض الأسعار هذا عبارات الوصف بما يصل إلى معدّل معيّن، ثم يبدأ في عرض استجابات "بدون عرض سعر" لأيّ زيادة في عدد الطلبات. على غرار مقدّم عروض الأسعار "خطأ في حالة التحميل الزائد"، يمكن تنفيذ ذلك بعدة طرق. والفرق هنا هو أنّه لا يتم إرسال أي إشارة إلى Google، لذا لا نحدّ أبدًا من عدد الرسوم التوضيحية. تمتص أجهزة الواجهة المهام الزائدة، ولا تسمح إلا بالزيارات التي يمكنها معالجتها للمتابعة إلى الخلفيات.
يعرض الرسم البياني لوقت الاستجابة لمقدّم عروض الأسعار هذا مستوى ثابتًا (بشكل مصطنع) يتوقف عن مواءمة معدّل الطلبات في أوقات الذروة، ويحدث انخفاض مناظر في نسبة الردود التي تحتوي على عرض سعر.
ننصح بدمج أسلوب "خطأ في حال حدوث زيادة في الحمل" مع أسلوب "عدم تقديم عروض أسعار في حال حدوث زيادة في الحمل"، وذلك على النحو التالي:
- يمكنك زيادة عدد واجهات برمجة التطبيقات وضبطها على الخطأ عند حدوث حمولة زائدة، للمساعدة في زيادة عدد عمليات الاتصال التي يمكنها الاستجابة لها بشكل أو بآخر.
- عند حدوث خطأ بسبب زيادة عدد الطلبات، يمكن للأجهزة في الواجهة الأمامية استخدام ردّ جاهز "بدون عرض سعر"، ولا تحتاج إلى تحليل الطلب على الإطلاق.
- تنفيذ عمليات التحقّق من صحة الخلفيات، بحيث إذا لم تتوفّر سعة كافية لأيّ منها، يتم عرض استجابة "بدون عرض سعر".
ويسمح ذلك بمعالجة بعض عمليات التحميل الزائد ويمنح الخلفيات فرصة للإجابة عن أكبر عدد ممكن من الطلبات. يمكنك اعتبار ذلك "عدم تقديم عرض سعر عند حدوث زيادة في عدد الطلبات"، مع الرجوع إلى "خطأ عند حدوث زيادة في عدد الطلبات" في أجهزة الواجهة عندما يكون عدد الطلبات أعلى بكثير من المتوقع.
إذا كان لديك مقدّم عروض أسعار "يتفاعل مع كلّ شيء"، ننصحك بتحويله إلى مقدّم عروض أسعار "يُرسِل خطأ عند التحميل الزائد" من خلال ضبط سلوك الاتصال لكي يرفض التحميل الزائد. على الرغم من أنّ ذلك يؤدي إلى عرض المزيد من الأخطاء، إلا أنّه يقلل من حالات انتهاء مهلة الطلب ويمنع الخادم من الوصول إلى حالة يتعذّر فيها عليه الردّ على أي طلبات.
تبادل المعلومات بين الشبكات
هناك طريقة أخرى لتقليل وقت استجابة الشبكة أو التباين، وهي الربط بخدمات Google. تساعد ميزة "الربط بين الخوادم" في تحسين المسار الذي تسلكه الزيارات للوصول إلى نظام عروض الأسعار. تظل نقاط نهاية الاتصال كما هي، ولكن تتغيّر الروابط الوسيطة. اطّلِع على دليل الربط للاطّلاع على التفاصيل. يمكن تلخيص سبب اعتبار الربط بين التطبيقات كأفضل ممارسة على النحو التالي:
على الإنترنت، يتم اختيار روابط النقل بشكل أساسي من خلال "توجيه الحزمة المتغيرة "، الذي يعثر على أقرب رابط خارج شبكتنا يمكنه نقل ملف ملتحم إلى وجهته، ويوجّه الحزمة من خلال هذا الرابط. عندما تعبر الزيارات قسمًا من العمود الفقري يملكه مقدّم خدمة لدينا معه العديد من عمليات الربط، من المرجّح أن يكون الرابط المحدّد قريبًا من مكان بدء الحزمة. بعد هذه المرحلة، لا يمكننا التحكّم في المسار الذي تسلكه الحزمة لتصل إلى مقدّم عروض الأسعار، لذا قد يتم إعادة توجيهها إلى أنظمة مستقلة (شبكات) أخرى على طول المسار.
في المقابل، عندما تكون هناك اتفاقية اتصال مباشر، يتم دائمًا إرسال الحزم عبر رابط اتصال. بغض النظر عن مصدر الحزمة، فإنّها تنتقل عبر الروابط التي تملكها Google أو تُستأجرها إلى أن تصل إلى نقطة اتصال المشترَكة التي من المفترض أن تكون قريبة من الموقع الجغرافي لمقدّم عروض الأسعار. تبدأ الرحلة العكسية بقفزة قصيرة إلى شبكة Google وتبقى على شبكة Google طوال الرحلة. إنّ إبقاء معظم الرحلة على البنية الأساسية التي تديرها Google يضمن اتّخاذ الحزمة لمسار يتسم بوقت استجابة منخفض، ويتجنّب الكثير من الاختلافات المحتملة.
إرسال نظام أسماء النطاقات الثابت
ننصحك دائمًا بأن يرسل المشترون نتيجة واحدة ثابتة لنظام أسماء النطاقات إلى Google ويعتمدوا على Google لمعالجة إرسال الزيارات.
في ما يلي عمليتان شائعتان من خوادم نظام أسماء النطاقات لمقدّمي عروض الأسعار عند محاولة تحميل موازنة أو إدارة مدى التوفّر:
- يقدّم خادم نظام أسماء النطاقات عنوانًا واحدًا أو مجموعة فرعية من العناوين استجابةً لطلب بحث، ثم ينتقل من خلال هذه الاستجابة بطريقة معيّنة.
- يستجيب خادم نظام أسماء النطاقات دائمًا بالمجموعة نفسها من العناوين، ولكنه يغيّر ترتيب العناوين في الاستجابة.
إنّ التقنية الأولى ضعيفة في موازنة الحمل لأنّ هناك الكثير من ذاكرة التخزين المؤقت في مستويات متعدّدة من الحزمة، ومن المحتمل أنّ محاولات تجاوز ذاكرة التخزين المؤقت لن تؤدي إلى الحصول على النتائج المفضّلة أيضًا لأنّ Google تفرض رسومًا على وقت حلّ نظام أسماء النطاقات على مقدم العروض.
لا تحقّق التقنية الثانية موازنة التحميل على الإطلاق لأنّ Google تختار عنوان IP بشكل عشوائي من قائمة ردّات نظام أسماء النطاقات، لذا لا يهمّ الترتيب في الردّ.
إذا أجرى مقدّم عروض أسعار تغييرًا في نظام أسماء النطاقات، ستلتزم Google بمدة البقاء(TTL) التي تم ضبطها في سجلّات نظام أسماء النطاقات، ولكن يبقى فاصل التحديث غير مؤكد.