Halaman ini diterjemahkan oleh Cloud Translation API.

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 memerlukan lebih banyak resource di kedua ujung daripada menggunakan kembali koneksi yang ada. Dengan menutup lebih sedikit koneksi, Anda dapat mengurangi jumlah koneksi yang harus dibuka lagi.

Pertama, setiap koneksi baru memerlukan proses dua arah jaringan tambahan untuk dibuat. Karena kami membuat koneksi sesuai permintaan, permintaan pertama pada koneksi memiliki batas waktu efektif yang lebih singkat dan lebih cenderung habis waktu tunggunya daripada permintaan berikutnya. 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. Artinya, untuk menutup dan membuat ulang koneksi, server harus dimatikan dan menghapus thread, mengalokasikan thread baru, membuatnya dapat dijalankan, dan membuat status koneksi, sebelum akhirnya memproses permintaan. Itu adalah banyak overhead yang tidak perlu.

Menghindari penutupan koneksi

Mulai dengan menyesuaikan perilaku koneksi. Sebagian besar setelan default server disesuaikan untuk lingkungan dengan banyak klien, yang masing-masing membuat sedikit 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 menjadi 2,5 menit.
Jumlah maksimum permintaan pada koneksi ke nilai tertinggi yang mungkin.
Jumlah maksimum koneksi ke nilai tertinggi yang dapat ditampung RAM Anda, sambil memastikan bahwa jumlah koneksi tidak terlalu mendekati nilai tersebut.

Misalnya, di Apache, hal ini akan memerlukan penetapan 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 secara tidak perlu. Misalnya, jika Anda memiliki kode frontend yang menampilkan respons "tidak ada bid" default jika terjadi error backend atau waktu tunggu habis, pastikan kode menampilkan responsnya tanpa menutup koneksi. Dengan begitu, Anda dapat menghindari situasi saat bidder Anda kelebihan beban, koneksi mulai ditutup, dan jumlah waktu tunggu meningkat, sehingga menyebabkan bidder Anda dibatasi.

Menjaga koneksi tetap seimbang

Jika Authorized Buyers terhubung ke server bidder Anda melalui server proxy, koneksi tersebut dapat menjadi tidak seimbang dari waktu ke waktu karena, hanya mengetahui alamat IP server proxy, Authorized Buyers tidak dapat menentukan server bidder mana yang menerima setiap info. Seiring waktu, saat Authorized Buyers membuat dan menutup koneksi serta server bidder dimulai ulang, jumlah koneksi yang dipetakan ke masing-masing 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 menemukan traffic menjadi tidak seimbang di lingkungan Anda, ada langkah lebih lanjut yang dapat Anda lakukan:

Pilih backend per permintaan, bukan sekali per koneksi, jika Anda menggunakan proxy frontend.
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. Di Apache, misalnya, tetapkan MaxKeepAliveRequests ke 5.000
Konfigurasikan server bidder untuk memantau rasio permintaannya dan menutup beberapa koneksinya sendiri jika secara konsisten menangani terlalu banyak permintaan dibandingkan dengan rekan-rekannya.

Menangani kelebihan beban dengan baik

Idealnya, kuota akan ditetapkan cukup tinggi sehingga bidder Anda dapat menerima semua permintaan yang dapat ditanganinya, tetapi tidak lebih dari itu. Dalam praktiknya, mempertahankan kuota pada tingkat optimal adalah tugas yang sulit, dan kelebihan beban memang terjadi, karena berbagai alasan: backend mengalami gangguan selama jam sibuk, campuran traffic berubah sehingga lebih banyak pemrosesan diperlukan untuk setiap permintaan, atau nilai kuota 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 saat beban berat, bidder dibagi menjadi tiga kategori yang luas:

Bidder "merespons semuanya"

Meskipun mudah diterapkan, bidder ini berperforma paling buruk saat dibebani. Sistem ini hanya mencoba merespons setiap permintaan bid yang masuk, apa pun kondisinya, dengan mengantrekan permintaan yang tidak dapat ditayangkan dengan segera. Skenario yang terjadi sering kali seperti ini:

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

Grafik latensi untuk bidder ini menyerupai pola gergaji yang sangat curam. 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.

Bidder "error on overload"

Bidder ini menerima info hingga tarif tertentu, lalu mulai menampilkan error 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.

Bidder "tidak ada bid saat kelebihan beban"

Bidder ini menerima info hingga tingkat tertentu, lalu mulai menampilkan respons "tidak ada bid" untuk kelebihan beban. Serupa dengan bidder "error on overload", hal ini dapat diterapkan dengan beberapa cara. Perbedaannya di sini adalah tidak ada sinyal yang ditampilkan ke Google, sehingga kami tidak pernah mengurangi kapasitas info. Kelebihan beban diserap oleh mesin frontend, yang hanya mengizinkan traffic yang dapat ditanganinya untuk dilanjutkan ke backend.

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

Sebaiknya gabungkan pendekatan "error saat kelebihan beban" dengan pendekatan "tidak ada bid saat kelebihan beban", dengan cara berikut:

Sediakan lebih banyak frontend dan tetapkan ke error saat kelebihan beban, untuk membantu memaksimalkan jumlah koneksi yang dapat direspons dalam beberapa bentuk.
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 kelebihan beban diserap dan memberi backend kesempatan untuk merespons permintaan sebanyak yang dapat ditanganinya. Anda dapat menganggapnya sebagai "tidak ada bid saat kelebihan beban" dengan mesin frontend kembali ke "error saat kelebihan beban" saat jumlah permintaan jauh lebih tinggi dari yang diharapkan.

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.

Pertimbangkan peering

Cara lain untuk mengurangi latensi atau variabilitas jaringan adalah dengan melakukan peering dengan Google. Peering membantu mengoptimalkan jalur yang dilalui traffic 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 diringkas sebagai berikut:

Di internet, link transit dipilih terutama melalui "hot-potato routing", yang menemukan link terdekat di luar jaringan kita yang dapat mengirim paket ke tujuannya, dan merutekan 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 berada di dekat tempat 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. Terlepas dari asalnya, paket akan melintasi link yang dimiliki atau disewa Google hingga mencapai titik peering bersama, yang harus berada di dekat lokasi bidder. Perjalanan balik dimulai dengan hop singkat ke jaringan Google dan tetap berada di jaringan Google selama perjalanan. Mempertahankan sebagian besar perjalanan di infrastruktur yang dikelola Google memastikan bahwa paket mengambil rute latensi rendah, dan menghindari banyak potensi variabilitas.

Mengirimkan DNS statis

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

Berikut adalah dua praktik umum dari server DNS bidder saat mencoba memuat saldo atau mengelola ketersediaan:

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

Teknik pertama kurang baik dalam load balancing karena ada banyak penyimpanan dalam cache di beberapa tingkat stack, dan upaya untuk mengabaikan penyimpanan dalam cache kemungkinan juga tidak akan mendapatkan hasil yang diinginkan karena Google mengenakan biaya waktu resolusi DNS kepada 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 membuat perubahan DNS, Google akan mematuhi TTL(Time-to-live) yang ditetapkan dalam data DNS-nya, tetapi interval pembaruan tetap tidak pasti.