Praktik Terbaik untuk Permohonan RTB

Panduan ini menjelaskan praktik terbaik yang perlu dipertimbangkan saat mengembangkan aplikasi sesuai dengan Protokol RTB.

Kelola koneksi

Jaga koneksi tetap aktif

Membuat koneksi baru akan meningkatkan latensi dan menghabiskan lebih banyak resource di kedua ujung daripada menggunakan kembali yang sudah ada. Dengan menutup lebih sedikit koneksi, Anda dapat mengurangi jumlah koneksi yang harus dibuka kembali.

Pertama, setiap koneksi baru memerlukan perjalanan bolak-balik jaringan tambahan untuk dibuat. Karena kita membuat koneksi sesuai permintaan, permintaan pertama pada koneksi memiliki batas waktu efektif yang lebih singkat dan cenderung memiliki waktu tunggu daripada permintaan berikutnya. Waktu tunggu tambahan akan meningkatkan rasio error, yang dapat menyebabkan bidder Anda di-throttle.

Kedua, banyak server web memunculkan thread pekerja khusus untuk setiap koneksi yang dibuat. Artinya, untuk menutup dan membuat ulang koneksi, server harus menonaktifkan dan menghapus thread, mengalokasikan thread baru, membuatnya dapat dijalankan, dan mem-build status koneksi, sebelum akhirnya memproses permintaan. Itu adalah banyak {i>overhead<i} yang tidak perlu.

Menghindari penutupan koneksi

Mulailah dengan menyesuaikan perilaku koneksi. Sebagian besar default server disesuaikan untuk lingkungan yang memiliki klien dalam jumlah besar, masing-masing membuat permintaan dalam jumlah kecil. Sebaliknya, untuk RTB, sekumpulan kecil mesin mengirimkan permintaan atas nama sejumlah besar browser, secara relatif berbicara. Dalam kondisi ini, koneksi sebanyak mungkin dapat digunakan kembali. Sebaiknya tetapkan:

  • Waktu tunggu tidak ada aktivitas menjadi 2,5 menit.
  • Jumlah maksimum permintaan pada koneksi ke nilai tertinggi yang memungkinkan.
  • Jumlah maksimum koneksi ke nilai tertinggi yang dapat diakomodasi oleh RAM, sambil berhati-hati untuk memastikan bahwa jumlah koneksi tidak mendekati nilai itu terlalu dekat.

Misalnya, di Apache, hal ini akan memerlukan setelan KeepAliveTimeout ke 150, MaxKeepAliveRequests ke nol, dan MaxClients ke nilai yang bergantung pada jenis server.

Setelah perilaku koneksi disesuaikan, Anda juga harus memastikan bahwa kode bidder tidak menutup koneksi dengan sia-sia. Misalnya, jika Anda memiliki kode frontend yang menampilkan respons "no bid" default jika terjadi error backend atau waktu tunggu habis, pastikan kode menampilkan responsnya tanpa menutup koneksi. Dengan demikian, Anda akan menghindari situasi yang jika bidder kelebihan beban, koneksi mulai ditutup, dan jumlah waktu tunggu meningkat, yang menyebabkan bidder dibatasi.

Jaga agar koneksi tetap seimbang

Jika Authorized Buyers terhubung ke server bidder Anda melalui server proxy, koneksi mungkin menjadi tidak seimbang dari waktu ke waktu karena, karena hanya mengetahui alamat IP server proxy, Authorized Buyers tidak dapat menentukan server bidder mana yang menerima setiap pemanggilan. Seiring waktu, saat Authorized Buyers membuat dan menutup koneksi dan server bidder dimulai ulang, jumlah koneksi yang dipetakan ke setiap koneksi dapat menjadi sangat bervariasi.

Saat beberapa koneksi sangat banyak digunakan, koneksi terbuka lainnya mungkin sebagian besar tetap tidak ada aktivitas karena tidak diperlukan pada saat itu. Seiring perubahan traffic Authorized Buyers, koneksi tidak ada aktivitas dapat menjadi aktif dan koneksi aktif dapat menjadi tidak ada aktivitas. Hal ini dapat menyebabkan pemuatan yang tidak merata pada server bidder jika koneksi dikelompokkan dengan buruk. Google berupaya mencegah hal ini dengan menutup semua koneksi setelah 10.000 permintaan, untuk menyeimbangkan kembali koneksi hot secara otomatis dari waktu ke waktu. Jika Anda masih mendapati traffic di lingkungan Anda menjadi tidak seimbang, ada langkah-langkah lebih lanjut yang dapat Anda ambil:

  1. Pilih backend per permintaan, bukan sekali per koneksi, jika Anda menggunakan proxy frontend.
  2. Tentukan jumlah maksimum permintaan per koneksi jika Anda membuat proxy koneksi melalui load balancer hardware atau firewall, dan pemetaannya akan diperbaiki setelah koneksi dibuat. Perhatikan bahwa Google telah menentukan batas maksimum 10.000 permintaan per koneksi sehingga Anda hanya perlu memberikan nilai yang lebih ketat jika masih menemukan koneksi hot yang terklaster di lingkungan Anda. Di Apache, misalnya, tetapkan MaxKeepAliveRequests ke 5.000
  3. Konfigurasikan server bidder untuk memantau rasio permintaannya dan menutup beberapa koneksinya sendiri jika mereka secara konsisten menangani terlalu banyak permintaan dibandingkan dengan pembandingnya.

Menangani overload dengan baik

Idealnya, kuota harus ditetapkan cukup tinggi sehingga bidder dapat menerima semua permintaan yang dapat ditanganinya, tetapi tidak lebih dari itu. Dalam praktiknya, mempertahankan kuota pada level yang optimal adalah tugas yang sulit, dan overload dapat terjadi karena berbagai alasan: backend mengalami gangguan selama waktu puncak, kombinasi traffic berubah sehingga diperlukan lebih banyak pemrosesan untuk setiap permintaan, atau nilai kuota yang ditetapkan terlalu tinggi. Oleh karena itu, sebaiknya pertimbangkan perilaku bidder Anda dengan terlalu banyak traffic yang masuk.

Untuk mengakomodasi pergeseran traffic sementara (hingga satu minggu) antar-region (terutama antara Asia & AS Barat dan AS Timur & AS Barat), kami merekomendasikan batasan 15% antara periode puncak 7 hari dan QPS per Lokasi Perdagangan.

Dalam hal perilaku di bawah beban berat, bidder termasuk dalam tiga kategori besar:

Bidder "tanggapi semuanya"

Meskipun mudah diimplementasikan, bidder ini menimbulkan dampak terburuk jika kelebihan beban. Sistem ini hanya mencoba merespons setiap permintaan bid yang masuk, apa pun apa pun, mengantrekan permintaan yang tidak dapat segera ditayangkan. Skenario yang terjadi sering kali seperti ini:

  • Seiring meningkatnya rasio permintaan, begitu pula latensi permintaan, hingga semua permintaan memulai waktu habis
  • Latensi meningkat drastis saat kecepatan pemanggilan mendekati puncak
  • Throttling mulai bekerja, secara tajam mengurangi jumlah info yang diizinkan
  • Latensi mulai pulih, sehingga menyebabkan throttling dikurangi
  • Siklus akan dimulai lagi.

Grafik latensi untuk bidder ini menyerupai pola gigi gergaji yang sangat curam. Atau, permintaan yang diantrekan menyebabkan server memulai memori paging atau melakukan hal lain yang menyebabkan pelambatan jangka panjang, dan latensi tidak pulih sama sekali hingga waktu puncaknya berakhir, sehingga menyebabkan penurunan frekuensi pemanggilan selama seluruh periode puncak. Dalam kedua kasus tersebut, lebih sedikit pemanggilan yang dibuat atau direspons daripada jika kuota hanya ditetapkan ke nilai yang lebih rendah.

Bidder "error saat kelebihan beban"

Bidder ini menerima pemanggilan hingga rasio tertentu, lalu mulai menampilkan error untuk beberapa pemanggilan. Hal ini dapat dilakukan melalui waktu tunggu internal, menonaktifkan antrean koneksi (dikontrol oleh ListenBackLog di Apache), menerapkan mode lepas probabilitas saat pemanfaatan atau latensi menjadi terlalu tinggi, atau mekanisme lainnya. Jika Google melihat tingkat error di atas 15%, kami akan memulai throttling. Tidak seperti bidder "respons terhadap semuanya", bidder ini "memotong kerugiannya", yang memungkinkannya segera pulih saat rasio permintaan turun.

Grafik latensi untuk bidder ini menyerupai pola gigi gergaji yang dangkal selama overload, yang dilokalkan di sekitar tingkat maksimum yang dapat diterima.

Bidder "tanpa bid pada kelebihan beban"

Bidder ini menerima pemanggilan hingga rasio tertentu, lalu mulai menampilkan respons "tanpa bid" untuk overload. Serupa dengan bidder "error saat kelebihan beban", hal ini dapat diterapkan dengan beberapa cara. Yang berbeda di sini adalah tidak ada sinyal yang ditampilkan ke Google, jadi kami tidak pernah memperlambat pemanggilan. Kelebihan beban akan diserap oleh mesin front-end, yang hanya memungkinkan traffic yang dapat ditangani untuk melanjutkan ke backend.

Grafik latensi untuk bidder ini menunjukkan dataran tinggi yang (secara artifisial) berhenti sejajar dengan rasio permintaan pada waktu puncak, dan penurunan yang sesuai dalam fraksi respons yang berisi bid.

Sebaiknya Anda menggabungkan "error saat kelebihan beban" dengan pendekatan "no-bid on overload", dengan cara berikut:

  • Menyediakan front-end secara berlebihan dan mengaturnya ke error saat kelebihan beban, untuk membantu memaksimalkan jumlah koneksi yang dapat direspons dalam beberapa bentuk.
  • Saat melakukan error saat terjadi kelebihan beban, mesin front-end dapat menggunakan respons "no-bid" yang telah direkam, dan tidak perlu mengurai permintaan sama sekali.
  • Implementasikan health check backend, sehingga jika tidak ada yang memiliki kapasitas memadai, backend akan menampilkan respons "tanpa bid".

Hal ini memungkinkan beberapa overload diserap dan memberi backend kesempatan untuk merespons permintaan sebanyak yang dapat ditangani. Anda dapat menganggapnya sebagai "tanpa bid pada kelebihan beban" dengan mesin frontend yang kembali ke "error saat overload" saat jumlah permintaan jauh lebih tinggi dari yang diperkirakan.

Jika Anda memiliki bidder "tanggapi semuanya", pertimbangkan untuk mengubahnya menjadi error pada bidder "error saat kelebihan beban" dengan menyesuaikan perilaku koneksi agar pada dasarnya menolak kelebihan beban. Meskipun dapat menyebabkan lebih banyak error yang ditampilkan, hal ini mengurangi waktu tunggu dan mencegah server masuk ke kondisi saat tidak dapat merespons permintaan apa pun.

Merespons ping

Sangat penting untuk memastikan bahwa bidder Anda dapat merespons permintaan ping, meskipun bukan pengelolaan koneksi itu sendiri. Google menggunakan permintaan ping untuk pemeriksaan kesehatan dan proses debug status bidder, perilaku penutupan koneksi, latensi, dan lainnya. Permintaan ping menggunakan bentuk berikut:

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

JSON OpenRTB

"id": "4YB27BCXimH5g7wB39nd3t"

Protobuf OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

Perlu diingat bahwa, berbeda dengan yang Anda harapkan, permintaan ping tidak berisi slot iklan apa pun. Dan, seperti yang dijelaskan di atas, Anda tidak boleh menutup koneksi setelah merespons permintaan ping.

Pertimbangkan peering

Cara lain untuk mengurangi latensi atau variabilitas jaringan adalah melakukan peering dengan Google. Peering membantu mengoptimalkan jalur traffic yang diambil untuk mencapai bidder Anda. Endpoint koneksi tetap sama, tetapi link perantara berubah. Lihat Panduan peering untuk mengetahui detailnya. Alasan untuk menganggap peering sebagai praktik terbaik dapat dirangkum sebagai berikut:

  • Di internet, link transportasi umum dipilih terutama melalui "pemilihan rute hot-potato", yang menemukan link terdekat di luar jaringan kami yang bisa menerima paket ke tujuannya, dan mengarahkan paket melalui link tersebut. Saat traffic melintasi bagian backbone yang dimiliki oleh penyedia yang memiliki banyak koneksi peering dengan kami, link yang dipilih kemungkinan akan dekat dengan tempat paket dimulai. Di luar titik tersebut, kami tidak memiliki kontrol atas rute yang diikuti oleh paket kepada bidder, sehingga paket tersebut mungkin dipantulkan ke sistem otonom lainnya (jaringan) selama prosesnya.

  • Sebaliknya, jika perjanjian peering langsung telah ditetapkan, paket akan selalu dikirim melalui link peering. Dari mana pun asal paket tersebut, paket akan melewati link yang dimiliki atau disewa Google hingga mencapai titik peering bersama, yang harus dekat dengan lokasi bidder. Perjalanan balik dimulai dengan hop singkat ke jaringan Google dan tetap berada di jaringan Google. Menyimpan sebagian besar perjalanan di infrastruktur yang dikelola Google akan memastikan bahwa paket tersebut mengambil rute latensi rendah, dan menghindari banyak potensi variabilitas.

Kirim DNS statis

Sebaiknya pembeli selalu mengirimkan satu hasil DNS statis ke Google dan mengandalkan Google untuk menangani pengiriman traffic.

Berikut dua praktik umum dari server DNS bidder saat mencoba melakukan load balancing atau mengelola ketersediaan:

  1. Server DNS memberikan satu alamat, atau subset alamat, sebagai respons atas kueri, lalu menelusuri respons ini dengan cara tertentu.
  2. Server DNS selalu merespons dengan kumpulan alamat yang sama, tetapi juga mengubah urutan alamat dalam respons.

Teknik pertama buruk pada load balancing karena ada banyak penyimpanan cache di beberapa level tumpukan, dan upaya untuk mengabaikan cache kemungkinan juga tidak akan mendapatkan hasil yang diinginkan karena Google menagih waktu resolusi DNS ke bidder.

Teknik kedua tidak mencapai load balancing sama sekali karena Google secara acak memilih alamat IP dari daftar respons DNS sehingga urutan respons tidak menjadi masalah.

Jika bidder membuat perubahan DNS, Google akan menerima TTL(Time-to-live) yang ditetapkan dalam data DNS-nya, tetapi interval refresh tetap tidak pasti.