Praktik Terbaik untuk Permohonan RTB

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

Kelola koneksi

Mempertahankan koneksi

Membuat koneksi baru akan meningkatkan latensi dan membutuhkan waktu yang jauh lebih sumber daya di kedua ujungnya daripada menggunakan kembali yang sudah ada. Dengan menutup lebih sedikit koneksi jarak jauh, Anda dapat mengurangi jumlah koneksi yang harus dibuka untuk mencoba lagi perintah.

Pertama, setiap koneksi baru memerlukan proses dua arah jaringan tambahan untuk dibuat. Karena kita membuat koneksi sesuai permintaan, permintaan pertama di koneksi memiliki tenggat waktu efektif yang lebih pendek dan lebih cenderung memiliki waktu habis daripada terhadap permintaan selanjutnya. Setiap waktu tunggu tambahan akan meningkatkan rasio error, yang dapat menyebabkan bidder Anda dibatasi.

Kedua, banyak server web membuat thread pekerja khusus untuk setiap koneksi yang dibuat. Ini berarti bahwa untuk menutup dan membuat ulang koneksi, server harus mematikan dan membuang thread, mengalokasikan thread baru, membuatnya dapat dijalankan, dan membangun status koneksi, sebelum akhirnya memproses permintaan. Banyak sekali {i>overhead<i} yang tidak perlu.

Menghindari penutupan koneksi

Mulailah dengan menyesuaikan perilaku koneksi. Sebagian besar setelan default server disesuaikan untuk lingkungan dengan banyak klien, yang masing-masing membuat sejumlah kecil permintaan. Sebaliknya, untuk RTB, sekumpulan kecil mesin mengirim permintaan atas nama browser dalam jumlah besar, secara relatif. Dalam kondisi ini, sebaiknya gunakan kembali koneksi sebanyak mungkin. Sebaiknya Anda menetapkan:

  • Waktu tunggu tidak ada aktivitas hingga 2,5 menit.
  • Jumlah maksimum permintaan pada koneksi ke nilai yang memungkinkan.
  • Jumlah koneksi maksimum ke nilai tertinggi yang dapat dilakukan RAM Anda mengakomodasi, sembari berhati-hati untuk memverifikasi bahwa jumlah koneksi tidak mendekati nilai tersebut.

Di Apache, misalnya, ini akan memerlukan pengaturan KeepAliveTimeout hingga 150, MaxKeepAliveRequests hingga nol, dan MaxClients ke nilai yang bergantung pada jenis server.

Setelah perilaku koneksi Anda disesuaikan, Anda juga harus memastikan bahwa kode bidder tidak menutup koneksi secara tidak perlu. 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 dapat menghindari situasi di mana jika bidder Anda mendapat kelebihan beban, koneksi mulai ditutup, dan jumlah waktu tunggu meningkat, yang menyebabkan bidder Anda dibatasi.

Menjaga koneksi tetap seimbang

Jika Authorized Buyers terhubung ke server bidder Anda melalui server {i>proxy<i}, koneksinya mungkin menjadi tidak seimbang seiring waktu karena, hanya dengan 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.

Jika beberapa koneksi digunakan secara intensif, koneksi lain yang terbuka mungkin tetap sebagian besar tidak ada aktivitas karena tidak diperlukan pada saat itu. Saat traffic Authorized Buyers berubah, koneksi tidak ada aktivitas dapat menjadi aktif dan koneksi aktif dapat menjadi tidak ada aktivitas. Hal ini dapat menyebabkan beban yang tidak merata pada server bidder Anda jika koneksi dikelompokkan dengan buruk. Google mencoba mencegah hal ini dengan menutup semua koneksi setelah 10.000 permintaan, untuk secara otomatis menyeimbangkan kembali koneksi yang aktif dari waktu ke waktu. Jika Anda masih mendapati lalu lintas tidak seimbang di 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 melakukan proxy koneksi melalui load balancer atau firewall hardware dan pemetaan diperbaiki setelah koneksi dibuat. Perhatikan bahwa Google telah menentukan batas atas 10.000 permintaan per koneksi, sehingga Anda hanya perlu memberikan nilai yang lebih ketat jika masih menemukan koneksi panas yang menjadi cluster di lingkungan Anda. Misalnya, di Apache, tetapkan MaxKeepAliveRequests ke 5.000
  3. Konfigurasi server bidder untuk memantau rasio permintaan mereka dan menutup beberapa koneksi mereka sendiri jika secara konsisten menangani terlalu banyak permintaan dibandingkan dengan rekan-rekan mereka.

Menangani overload dengan baik

Idealnya, kuota ditetapkan cukup tinggi sehingga bidder Anda dapat menerima semua permintaan yang dapat ditangani, tetapi tidak lebih dari itu. Dalam praktiknya, mempertahankan kuota tingkat optimal adalah tugas yang sulit, dan kelebihan beban memang terjadi, untuk berbagai alasan: backend turun selama waktu puncak, campuran lalu lintas berubah sehingga lebih banyak pemrosesan diperlukan untuk setiap permintaan, atau nilai kuota yang baru saja 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 & Amerika Serikat Barat dan Amerika Serikat Timur & Amerika Serikat Barat), sebaiknya berikan buffer 15% antara puncak 7 hari dan QPS per Lokasi Perdagangan.

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

Bidder "merespons semuanya"

Meskipun mudah diterapkan, bidder ini memiliki performa terburuk ketika kelebihan beban. ECPC hanya mencoba merespons setiap permintaan bid yang masuk, bukan masalah, mengantrekan apa pun yang tidak bisa segera disajikan. Skenario yang terjadi sering kali seperti ini:

  • Seiring meningkatnya rasio permintaan, latensi permintaan juga akan meningkat, hingga semua permintaan mulai habis waktunya
  • Latensi meningkat tajam saat rasio pemanggilan mendekati puncak
  • Pembatasan akan diterapkan, sehingga mengurangi jumlah info yang diizinkan secara drastis
  • Latensi mulai pulih, sehingga throttling dikurangi
  • Siklus untuk dimulai lagi.

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

"Error pada kelebihan beban" bidder

Bidder ini menerima pemanggilan hingga tarif tertentu, lalu mulai kembali untuk beberapa info. Hal ini dapat dilakukan melalui waktu tunggu internal, menonaktifkan antrean koneksi (dikontrol oleh ListenBackLog di Apache), menerapkan mode drop probabilistik saat penggunaan atau latensi menjadi terlalu tinggi, atau beberapa mekanisme lainnya. Jika Google mengamati tingkat error di atas 15%, kami akan mulai melakukan throttling. Tidak seperti bidder "merespons semuanya", bidder ini "mengurangi kerugiannya", yang memungkinkannya segera pulih saat rasio permintaan menurun.

Grafik latensi untuk bidder ini menyerupai pola gergaji dangkal selama kelebihan beban, yang dilokalkan di sekitar kecepatan maksimum yang dapat diterima.

"Tidak ada bid saat kelebihan beban" bidder

Bidder ini menerima pemanggilan hingga tarif tertentu, lalu mulai kembali "tidak ada bid" respons jika terjadi kelebihan beban. Mirip dengan "error pada kelebihan beban" sebagai bidder, ini dapat diterapkan dalam beberapa cara. Perbedaannya di sini adalah tidak ada sinyal yang ditampilkan ke Google, sehingga kami tidak pernah mengurangi kapasitas info. Tujuan kelebihan beban diserap oleh komputer {i>front-end<i}, yang hanya memungkinkan lalu lintas data yang dapat mereka tangani untuk terus berlanjut ke backend.

Grafik latensi untuk bidder ini menunjukkan dataran tinggi yang (buatan) berhenti memparalelkan rasio permintaan pada waktu puncak, dan penurunan yang terkait bagian respons yang berisi tawaran.

Sebaiknya gabungkan "error pada kelebihan beban" dengan "tidak ada bid pada kelebihan beban" dengan cara berikut:

  • Menyediakan front end secara berlebihan dan menyetelnya ke error saat kelebihan beban, untuk membantu memaksimalkan jumlah koneksi yang dapat direspons dalam bentuk tertentu.
  • Saat terjadi error karena kelebihan beban, mesin frontend dapat menggunakan respons "no-bid" standar, dan tidak perlu mengurai permintaan sama sekali.
  • Terapkan pemeriksaan kondisi backend, sehingga jika tidak ada yang memiliki kapasitas yang memadai, backend akan menampilkan respons "tidak ada bid".

Hal ini memungkinkan beberapa overload untuk diserap dan memberikan backend kesempatan untuk menanggapi permintaan sebanyak yang mereka bisa tangani. Anda dapat membayangkan hal ini sebagai "tidak ada bid pada kelebihan beban" di mana komputer {i>front-end<i} kembali ke “{i>error <i}di kelebihan beban" saat jumlah permintaan jauh lebih tinggi dari yang diperkirakan.

Jika Anda memiliki bidder "respons terhadap semuanya", pertimbangkan untuk mengubahnya menjadi bidder "error saat kelebihan beban" dengan menyesuaikan perilaku koneksi sehingga pada dasarnya menolak kelebihan beban. Meskipun hal ini menyebabkan lebih banyak error ditampilkan, hal ini akan mengurangi waktu tunggu dan mencegah server berada dalam status yang tidak dapat merespons permintaan apa pun.

Merespons ping

Memastikan bidder Anda dapat merespons permintaan ping, tanpa koneksi itu sendiri, secara mengejutkan penting untuk {i>debugging<i}. Google menggunakan permintaan ping untuk pemeriksaan keandalan dan proses debug status bidder, perilaku penutupan koneksi, latensi, dan lainnya. Permintaan ping menggunakan bentuk berikut:

Protobuf OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

JSON OpenRTB

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

Google (Tidak digunakan lagi)

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

Perlu diingat bahwa, bertentangan dengan yang Anda harapkan, permintaan {i>ping<i} tidak berisi slot iklan. Selain itu, 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 dengan peering dengan Google. Peering membantu mengoptimalkan jalur yang dilalui traffic untuk mencapai bidder Anda. Tujuan endpoint koneksi tetap sama, tetapi link perantara berubah. Lihat Panduan peering untuk mengetahui detailnya. Tujuan alasan untuk menganggap peering sebagai praktik terbaik dapat diringkas sebagai berikut:

  • Di internet, link transportasi umum dipilih terutama melalui "hot-potato {i>routing<i}," yang menemukan tautan terdekat di luar jaringan kita yang bisa mendapatkan paket ke tujuannya, dan mengarahkan paket melalui tautan tersebut. Kapan melewati bagian backbone yang dimiliki oleh penyedia yang memiliki banyak koneksi peering, link yang dipilih cenderung dekat dengan paket dimulai. Setelah titik tersebut, kami tidak memiliki kontrol atas rute yang diikuti paket ke bidder, sehingga paket tersebut dapat di-bounce ke sistem otonom (jaringan) lain di sepanjang perjalanan.

  • Sebaliknya, jika perjanjian peering langsung diterapkan, paket selalu dikirim melalui link peering. Tidak peduli dari mana paket berasal, melintasi tautan yang dimiliki atau disewa oleh Google hingga mencapai tautan titik peering, yang harus dekat dengan lokasi bidder. Perjalanan balik dimulai dengan hop singkat ke jaringan Google dan tetap berada di jaringan Google selama perjalanan. Memastikan sebagian besar perjalanan dikelola Google memastikan bahwa paket tersebut mengambil rute berlatensi rendah, dan menghindari banyak potensi variabilitas.

Mengirimkan DNS statis

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

Berikut dua praktik umum dari bidder Server DNS saat mencoba memuat menyeimbangkan atau mengelola ketersediaan:

  1. Server DNS memberikan satu alamat, atau sebagian alamat, sebagai respons terhadap kueri, lalu melakukan siklus respons ini dengan cara tertentu.
  2. Server DNS selalu merespons dengan kumpulan alamat yang sama, tetapi mengurutkan alamat dalam respons secara berulang.

Teknik pertama tidak baik dalam {i>load balancing<i} karena ada banyak {i>caching<i} di beberapa tingkat tumpukan, dan upaya untuk mengabaikan {i>caching<i} kemungkinan besar tidak mendapatkan hasil yang diinginkan juga karena Google mengenakan waktu resolusi DNS ke menjadi bidder.

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

Jika bidder melakukan perubahan DNS, Google akan mematuhi TTL(Time-to-live) yang dalam catatan DNS-nya, tetapi interval pembaruannya tetap tidak pasti.