Praktik Terbaik untuk Permohonan RTB

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

Kelola koneksi

Menjaga hubungan tetap hidup

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 membutuhkan perjalanan bolak-balik jaringan bangun. 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 tingkat kesalahan, yang dapat menyebabkan kepada bidder Anda yang dibatasi.

Kedua, banyak server web menghasilkan thread pekerja khusus untuk setiap koneksi mapan. 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.

Hindari menutup koneksi

Mulailah dengan menyesuaikan perilaku koneksi. Sebagian besar {i>default<i} server disesuaikan untuk lingkungan dengan sejumlah besar klien, yang masing-masing menghasilkan permintaan. Sebaliknya, untuk RTB, sekelompok kecil mesin mengirimkan permintaan bagi banyak {i>browser<i}, secara relatif. Di bawah ini masuk akal, masuk akal untuk menggunakan kembali koneksi sesering mungkin. Rab 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 front-end yang menampilkan nilai default "tidak ada bid" respons jika backend atau waktu tunggu habis, pastikan kode mengembalikan responsnya tanpa menutup koneksi jarak jauh. 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.

Jaga keseimbangan

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 yang dimulai ulang, jumlah koneksi dipetakan ke masing-masing bagian bisa menjadi sangat bervariasi.

Ketika beberapa koneksi banyak digunakan, koneksi terbuka lainnya sebagian besar tetap tidak ada aktivitas karena tidak diperlukan pada saat itu. Sebagai Traffic Authorized Buyers berubah, koneksi yang tidak ada aktivitas dapat menjadi aktif dan aktif koneksi dapat menjadi tidak ada aktivitas. Hal ini dapat menyebabkan pemuatan yang tidak merata di server bidder Anda jika koneksi dikelompokkan dengan buruk. Google berusaha mencegah hal ini dengan menutup semua koneksi setelah 10.000 permintaan, untuk secara otomatis menyeimbangkan kembali hot koneksi dari waktu ke waktu. Jika Anda masih mendapati traffic 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 membuat proxy koneksi melalui load balancer hardware atau firewall pemetaan menjadi diperbaiki setelah koneksi dibuat. Perhatikan bahwa Google sudah menentukan batas atas 10.000 permintaan per koneksi, jadi Anda hanya perlu memberikan nilai yang lebih ketat jika Anda masih menemukan koneksi yang dikelompokkan di lingkungan Anda. Di Apache, misalnya, tetapkan MaxKeepAliveRequests menjadi 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. Karenanya, ada baiknya untuk mempertimbangkan perilaku bidder Anda terlalu banyak lalu lintas yang masuk.

Untuk mengakomodasi perpindahan lalu lintas sementara (hingga satu minggu) antar-wilayah (terutama antara Asia &AS Barat dan AS Timur &AS Barat), kami merekomendasikan batas 15% antara puncak 7 hari dan QPS per Trading Lokasi.

Terkait perilaku di bawah beban berat, bidder terbagi dalam tiga jenis kategori:

"Respons terhadap semuanya" bidder

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 pun meningkat, hingga semua permintaan waktu mulai habis
• Latensi meningkat tajam saat rasio pemanggilan mendekati puncak
• Throttling dimulai, yang secara tajam mengurangi jumlah info yang diizinkan
• Latensi mulai dipulihkan, menyebabkan throttling berkurang
• Siklus untuk dimulai lagi.

Grafik latensi untuk bidder ini menyerupai gergaji gergaji yang sangat curam pola. Atau, permintaan dalam antrean menyebabkan server memulai paging memori atau melakukan hal lain yang menyebabkan perlambatan jangka panjang, dan latensi tidak pulih sama sekali sampai waktu puncak berakhir, yang menyebabkan pemanggilan yang tertekan selama seluruh periode puncak. Dalam kedua kasus tersebut, lebih sedikit info yang dibuat atau ditanggapi daripada jika kuota 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 penurunan probabilistik ketika pemanfaatan atau latensi terlalu tinggi, atau mekanisme lainnya. Jika Google mengamati tingkat error di atas 15%, kita akan memulai throttling. Berbeda dengan "{i>responding to all<i}" bidder ini, bidder ini "memotong kerugiannya," sehingga dapat segera dipulihkan saat rasio permintaan ke bawah.

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

"Tidak ada bid saat kelebihan beban" bidder

Bidder ini menerima pemanggilan hingga tarif tertentu, lalu mulai kembali "tidak ada bid" respons yang berlebihan jika terjadi kelebihan beban. Mirip dengan "error pada kelebihan beban" sebagai bidder, ini dapat diterapkan dalam beberapa cara. Yang berbeda di sini adalah sinyal dikembalikan ke Google, sehingga kami tidak akan pernah membatasi 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.
• Ketika terjadi kesalahan pada kelebihan beban, mesin front-end dapat menggunakan template "tidak ada bid" respons standar, dan tidak perlu mengurai permintaan sama sekali.
• Mengimplementasikan pemeriksaan kondisi backend, sehingga jika tidak ada kapasitas yang memadai, backend akan menampilkan "no-bid" yang dihasilkan.

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 respons "respons ke semuanya" pertimbangkan untuk mengubahnya menjadi "error pada kelebihan beban" bidder dengan menyesuaikan perilaku koneksi agar dapat menolak untuk kelebihan beban. Meskipun ini menyebabkan lebih banyak error, mengurangi waktu tunggu dan mencegah server masuk ke kondisi 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 ping permintaan untuk pemeriksaan kesehatan dan proses debug status bidder, penutupan koneksi perilaku, latensi, dan banyak lagi. Permintaan ping menggunakan bentuk berikut:

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"

Perlu diingat bahwa, bertentangan dengan yang Anda harapkan, permintaan {i>ping<i} tidak berisi slot iklan. Dan, seperti yang diuraikan 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 diambil traffic untuk menjangkau bidder Anda. Tujuan endpoint koneksi tetap sama, tetapi link perantara berubah. Lihat Panduan peering untuk mengetahui detail. 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. Di luar titik itu, kita tidak memiliki kontrol atas rute paket mengikuti bidder, sehingga dapat dipantulkan ke sistem otonom lain (jaringan) di sepanjang perjalanan.

• Sebaliknya, ketika perjanjian peering langsung ada, paket akan 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 perjalanan singkat ke jaringan Google dan tetap berada di jaringan selama selanjutnya. Memastikan sebagian besar perjalanan dikelola Google memastikan bahwa paket tersebut mengambil rute berlatensi rendah, dan menghindari banyak potensi variabilitas.

Kirim 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 subset alamat, sebagai tanggapan ke kueri, dan kemudian merotasi respons ini dengan cara tertentu.
2. Server DNS selalu merespons dengan kumpulan alamat yang sama, tetapi siklus urutan alamat dalam respons.

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 dari daftar respons DNS secara acak sehingga urutan dalam tidak masalah.

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