بهترین روش ها برای برنامه های کاربردی RTB

این راهنما بهترین روش‌هایی را که باید در هنگام توسعه برنامه‌ها طبق پروتکل RTB در نظر گرفته شود، توضیح می‌دهد.

ارتباطات را مدیریت کنید

ارتباطات را زنده نگه دارید

ایجاد یک اتصال جدید تاخیرها را افزایش می دهد و منابع بسیار بیشتری را در هر دو طرف نسبت به استفاده مجدد از یک موجود می گیرد. با بستن اتصالات کمتر، می توانید تعداد اتصالاتی را که باید دوباره باز شوند کاهش دهید.

اول، هر اتصال جدید برای ایجاد نیاز به یک شبکه رفت و برگشت اضافی دارد. از آنجایی که ما اتصالات را بر اساس تقاضا برقرار می کنیم، اولین درخواست در یک اتصال مهلت موثر کوتاه تری دارد و احتمال اینکه زمان آن بیشتر از درخواست های بعدی باشد بیشتر است. هر وقفه اضافی نرخ خطا را افزایش می دهد، که می تواند منجر به کاهش قیمت پیشنهاد دهنده شما شود.

دوم، بسیاری از وب سرورها برای هر اتصال ایجاد شده، یک موضوع کاری اختصاصی ایجاد می کنند. این بدان معناست که برای بستن و ایجاد مجدد اتصال، سرور باید قبل از پردازش درخواست، یک رشته را خاموش کند و دور بیندازد، یک رشته جدید را اختصاص دهد، آن را قابل اجرا کند و وضعیت اتصال را بسازد. این مقدار زیادی سربار غیر ضروری است.

از بستن اتصالات خودداری کنید

با تنظیم رفتار اتصال شروع کنید. اکثر پیش‌فرض‌های سرور برای محیط‌هایی با تعداد مشتریان زیاد طراحی شده‌اند که هر کدام تعداد کمی درخواست دارند. در مقابل، برای RTB، مجموعه کوچکی از ماشین‌ها درخواست‌ها را از طرف تعداد زیادی مرورگر ارسال می‌کنند. در این شرایط، استفاده مجدد از اتصالات تا آنجا که ممکن است منطقی است. توصیه می کنیم تنظیم کنید:

• تایم اوت بیکار تا 2.5 دقیقه.
• حداکثر تعداد درخواست برای اتصال به بالاترین مقدار ممکن.
• حداکثر تعداد اتصالات به بالاترین مقداری که RAM شما می تواند داشته باشد، در حالی که مراقب باشید که تعداد اتصالات به آن مقدار نزدیک نباشد.

برای مثال، در Apache، این امر مستلزم تنظیم KeepAliveTimeout روی 150، MaxKeepAliveRequests روی صفر، و MaxClients به مقداری است که به نوع سرور بستگی دارد.

هنگامی که رفتار اتصال شما تنظیم شد، همچنین باید اطمینان حاصل کنید که کد پیشنهادی شما اتصالات را بیهوده نمی‌بندد. به عنوان مثال، اگر کد جلویی دارید که در صورت بروز خطا یا وقفه زمانی، یک پاسخ پیش‌فرض «بدون پیشنهاد» را برمی‌گرداند، مطمئن شوید که کد بدون بستن اتصال، پاسخ خود را برمی‌گرداند. به این ترتیب از موقعیتی جلوگیری می کنید که در آن اگر پیشنهاد دهنده شما بیش از حد بار شود، اتصالات شروع به بسته شدن می کنند و تعداد دفعات بازه زمانی افزایش می یابد و باعث می شود که پیشنهاد دهنده شما تحت فشار قرار گیرد.

ارتباطات را متعادل نگه دارید

اگر خریداران مجاز از طریق یک سرور پراکسی به سرورهای پیشنهاد دهنده شما متصل شوند، ممکن است به مرور زمان اتصالات نامتعادل شوند، زیرا خریداران مجاز تنها با دانستن آدرس IP سرور پراکسی، نمی توانند تعیین کنند که کدام سرور پیشنهاد دهنده هر تماس را دریافت می کند. با گذشت زمان، با ایجاد و بستن اتصالات توسط خریداران مجاز و راه اندازی مجدد سرورهای پیشنهاد دهنده، تعداد اتصالات نگاشت شده به هر یک می تواند بسیار متغیر باشد.

هنگامی که برخی از اتصالات به شدت مورد استفاده قرار می گیرند، سایر اتصالات باز ممکن است عمدتاً بیکار بمانند زیرا در آن زمان مورد نیاز نیستند. همانطور که ترافیک خریداران مجاز تغییر می کند، اتصالات بیکار می توانند فعال شوند و اتصالات فعال می توانند غیرفعال شوند. اگر اتصالات به خوبی خوشه بندی نشده باشند، ممکن است باعث بارهای ناهموار در سرورهای پیشنهاد دهنده شما شوند. گوگل تلاش می کند تا با بستن تمام اتصالات پس از 10000 درخواست از این امر جلوگیری کند تا به مرور زمان اتصالات داغ را مجدداً متعادل کند. اگر همچنان متوجه می‌شوید که ترافیک در محیط شما نامتعادل است، می‌توانید اقدامات بیشتری را انجام دهید:

1. اگر از پروکسی‌های فرانت‌اند استفاده می‌کنید، به‌جای یک بار در هر اتصال، پشتیبان را برای هر درخواست انتخاب کنید.
2. اگر اتصالات را از طریق یک متعادل کننده بار سخت افزاری یا فایروال پروکسی می کنید و پس از برقراری اتصالات، نقشه برداری ثابت می شود، حداکثر تعداد درخواست در هر اتصال را مشخص کنید. توجه داشته باشید که Google در حال حاضر حداکثر 10000 درخواست برای هر اتصال را مشخص کرده است، بنابراین اگر هنوز متوجه شدید که اتصالات داغ در محیط شما خوشه می‌شوند، فقط باید مقدار دقیق‌تری ارائه دهید. برای مثال در آپاچی، MaxKeepAliveRequests روی 5000 تنظیم کنید
3. سرورهای مناقصه‌دهنده را پیکربندی کنید تا بر نرخ‌های درخواست آنها نظارت داشته باشند و اگر به طور مداوم درخواست‌های زیادی را در مقایسه با همتایان خود رسیدگی می‌کنند، برخی از اتصالات خود را ببندند.

بار اضافی را با ظرافت مدیریت کنید

در حالت ایده آل، سهمیه ها به اندازه کافی بالا تعیین می شوند تا پیشنهاد دهنده شما بتواند تمام درخواست هایی را که می تواند انجام دهد، دریافت کند، اما نه بیشتر از آن. در عمل، حفظ سهمیه ها در سطوح بهینه کار دشواری است، و اضافه بارها به دلایل مختلفی اتفاق می‌افتد: عقب ماندگی در زمان اوج مصرف، تغییر ترکیب ترافیک به طوری که برای هر درخواست پردازش بیشتری لازم است، یا مقدار سهمیه. فقط خیلی بالا تنظیم شده در نتیجه، در نظر گرفتن اینکه پیشنهاد دهنده شما چگونه با ترافیک بیش از حد وارد می شود، ارزش دارد.

برای جابجایی ترافیک موقت (حداکثر یک هفته) بین مناطق (به ویژه بین آسیا و غرب ایالات متحده و شرق ایالات متحده و غرب ایالات متحده)، ما یک بالشتک 15٪ بین اوج 7 روزه و QPS در هر مکان معامله را توصیه می کنیم.

از نظر رفتار تحت بارهای سنگین، پیشنهاد دهندگان به سه دسته کلی تقسیم می شوند:

مناقصه گزار "به همه چیز پاسخ دهید".

در حالی که اجرای آن ساده است، اما در صورت بارگذاری بیش از حد، این پیشنهاد دهنده بدترین عملکرد را دارد. صرفاً سعی می‌کند به هر درخواست پیشنهادی که وارد می‌شود، بدون توجه به آنچه که می‌شود، پاسخ دهد و هر درخواستی را که نمی‌تواند فوراً ارائه شود، در صف قرار می‌دهد. سناریویی که اتفاق می افتد اغلب چیزی شبیه به این است:

• همانطور که نرخ درخواست بالا می رود، تاخیرهای درخواست نیز افزایش می یابد، تا زمانی که تمام درخواست ها شروع به اتمام کنند
• با نزدیک شدن نرخ تماس به اوج، تاخیرها به سرعت افزایش می یابد
• ضربان قلب شروع می شود و تعداد تماس های مجاز را به شدت کاهش می دهد
• تأخیرها شروع به بهبود می کنند و باعث کاهش گلوگاه می شود
• چرخه برای شروع دوباره

نمودار تاخیر برای این پیشنهاد دهنده شبیه یک الگوی دندانه اره بسیار شیب دار است. از طرف دیگر، درخواست‌های در صف باعث می‌شوند که سرور حافظه صفحه‌بندی را شروع کند یا کار دیگری انجام دهد که باعث کندی طولانی‌مدت می‌شود، و تاخیرها تا پایان زمان اوج به هیچ وجه بهبود نمی‌یابند، که منجر به کاهش نرخ تماس در کل دوره پیک می‌شود. در هر صورت، فراخوان های کمتری نسبت به زمانی که سهمیه صرفاً روی مقدار کمتری تنظیم شده بود، ساخته یا پاسخ داده می شود.

پیشنهاد دهنده "خطا در اضافه بار".

این مناقصه‌دهنده فراخوان‌ها را تا یک نرخ مشخص می‌پذیرد، سپس شروع به بازگرداندن خطاها برای برخی از فراخوان‌ها می‌کند. این ممکن است از طریق وقفه های زمانی داخلی، غیرفعال کردن صف اتصال (که توسط ListenBackLog در آپاچی کنترل می شود)، اجرای یک حالت افت احتمالی زمانی که استفاده یا تأخیر بیش از حد بالا می رود، یا مکانیسم دیگری انجام شود. اگر گوگل نرخ خطای بالای 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

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

توجه داشته باشید که درخواست های پینگ OpenRTB شامل سیگنال is_ping نمی شود. این به این دلیل است که مدل OpenRTB فیلد پینگ ندارد، بنابراین یک درخواست پینگ موقت ارسال می‌شود، این یک BidRequest است که فقط حاوی شناسه است. مناقصه گران برای این کار نیازی به رسیدگی خاصی ندارند. رفتار عادی پاسخی را بدون هیچ پیشنهادی برمی‌گرداند.

به خاطر داشته باشید که برخلاف آنچه شما انتظار دارید، درخواست پینگ حاوی هیچ جایگاه تبلیغاتی نیست. و همانطور که در بالا توضیح داده شد ، پس از پاسخ به درخواست پینگ نباید اتصال را ببندید.

همتا کردن را در نظر بگیرید

راه دیگر برای کاهش تاخیر یا تغییرپذیری شبکه، همتا کردن با گوگل است. همتاسازی به بهینه سازی مسیری که ترافیک طی می کند تا به پیشنهاد دهنده شما برسد، کمک می کند. نقاط پایانی اتصال ثابت می مانند، اما پیوندهای میانی تغییر می کنند. برای جزئیات به راهنمای Peering مراجعه کنید. دلیل اندیشیدن به همتا به عنوان بهترین روش را می توان به صورت زیر خلاصه کرد:

• در اینترنت، پیوندهای ترانزیت عمدتاً از طریق "مسیریابی سیب زمینی داغ" انتخاب می شوند، که نزدیک ترین پیوند را در خارج از شبکه ما پیدا می کند که می تواند بسته را به مقصد برساند و بسته را از طریق آن پیوند هدایت می کند. هنگامی که ترافیک بخشی از ستون فقرات متعلق به ارائه‌دهنده‌ای که با او ارتباطات همتای زیادی داریم عبور می‌کند، احتمالاً پیوند انتخاب شده نزدیک به جایی است که بسته شروع می‌شود. فراتر از آن نقطه، ما هیچ کنترلی روی مسیری که بسته به مناقصه‌گذار دنبال می‌کند نداریم، بنابراین ممکن است در طول مسیر به سایر سیستم‌های مستقل (شبکه‌ها) بازگردد.

• در مقابل، زمانی که یک توافق نامه همتای مستقیم برقرار است، بسته ها همیشه در امتداد یک پیوند همتا ارسال می شوند. مهم نیست که بسته از کجا منشا می گیرد، پیوندهایی را که Google مالک یا اجاره می کند تا زمانی که به نقطه همتای مشترک، که باید نزدیک به محل پیشنهاد دهنده باشد، برسد، عبور می کند. سفر معکوس با یک پرش کوتاه به شبکه گوگل آغاز می شود و بقیه راه در شبکه گوگل باقی می ماند. نگه داشتن بیشتر سفر در زیرساخت های مدیریت شده توسط گوگل تضمین می کند که بسته مسیری با تاخیر کم را طی می کند و از تنوع بالقوه زیادی جلوگیری می کند.

DNS ایستا را ارسال کنید

ما به خریداران توصیه می کنیم همیشه یک نتیجه DNS ثابت را به Google ارسال کنند و برای رسیدگی به تحویل ترافیک به Google تکیه کنند.

در اینجا دو روش متداول از سرورهای DNS پیشنهاد دهندگان هنگام تلاش برای بارگیری تعادل یا مدیریت در دسترس بودن آورده شده است:

1. سرور DNS یک آدرس یا زیرمجموعه ای از آدرس ها را در پاسخ به یک پرس و جو ارائه می کند و سپس به نوعی در این پاسخ چرخه می کند.
2. سرور DNS همیشه با مجموعه ای از آدرس ها پاسخ می دهد، اما ترتیب آدرس ها را در پاسخ چرخه می کند.

تکنیک اول در تعادل بار ضعیف است زیرا حافظه پنهان زیادی در سطوح مختلف پشته وجود دارد، و تلاش برای دور زدن کش کردن احتمالاً نتایج ترجیحی را به دست نخواهد آورد زیرا Google زمان تفکیک DNS را از پیشنهاد دهنده دریافت می کند.

تکنیک دوم به هیچ وجه به تعادل بار نمی رسد زیرا گوگل به طور تصادفی یک آدرس IP را از لیست پاسخ DNS انتخاب می کند بنابراین ترتیب در پاسخ مهم نیست.

اگر پیشنهاد دهنده ای تغییری در DNS ایجاد کند، Google TTL (زمان تا زندگی) را که در سوابق DNS تنظیم شده است، رعایت می کند، اما فاصله بازخوانی نامشخص باقی می ماند.