แนวทางปฏิบัติแนะนำสำหรับแอปพลิเคชัน RTB

คู่มือนี้อธิบายแนวทางปฏิบัติแนะนำที่ควรคำนึงถึงเมื่อพัฒนาแอปพลิเคชันตามโปรโตคอล RTB

จัดการการเชื่อมต่อ

รักษาการเชื่อมต่อไว้

การสร้างการเชื่อมต่อใหม่จะเพิ่มเวลาในการตอบสนองและใช้ทรัพยากรทั้ง 2 ด้านมากกว่าการใช้การเชื่อมต่อที่มีอยู่ซ้ำ การปิดการเชื่อมต่อน้อยลงจะช่วยลดจํานวนการเชื่อมต่อที่ต้องเปิดอีกครั้ง

ประการแรกคือการเชื่อมต่อใหม่ทุกรายการต้องมีการส่งข้อมูลไปกลับในเครือข่ายเพิ่มเติมเพื่อที่จะสร้างการเชื่อมต่อ เนื่องจากเราสร้างการเชื่อมต่อตามคําขอ คำขอแรกในการเชื่อมต่อจึงมีกำหนดเวลาที่มีผลสั้นกว่าและมีแนวโน้มที่จะหมดเวลาเร็วกว่าคำขอต่อๆ มา การหมดเวลาเพิ่มเติมจะเพิ่มอัตราข้อผิดพลาด ซึ่งอาจทําให้ระบบจํากัดผู้เสนอราคา

ประการที่ 2 เว็บเซิร์ฟเวอร์หลายตัวจะสร้างเธรดผู้ปฏิบัติงานเฉพาะสำหรับการเชื่อมต่อแต่ละรายการที่สร้างขึ้น ซึ่งหมายความว่าหากต้องการปิดและสร้างการเชื่อมต่ออีกครั้ง เซิร์ฟเวอร์จะต้องปิดและทิ้งเธรด จองเธรดใหม่ ทําให้ทํางานได้ และสร้างสถานะการเชื่อมต่อ จากนั้นจึงประมวลผลคําขอ ซึ่งจะทำให้เกิดค่าใช้จ่ายที่ไม่จำเป็นจำนวนมาก

หลีกเลี่ยงการปิดการเชื่อมต่อ

เริ่มต้นด้วยการปรับลักษณะการเชื่อมต่อ ค่าเริ่มต้นส่วนใหญ่ของเซิร์ฟเวอร์จะปรับให้เหมาะกับสภาพแวดล้อมที่มีไคลเอ็นต์จํานวนมาก โดยแต่ละไคลเอ็นต์จะส่งคําขอจํานวนไม่มาก ในทางตรงกันข้าม สําหรับ RTB จะมีเครื่องจํานวนไม่มากที่ส่งคําขอในนามของเบราว์เซอร์จํานวนมาก ภายใต้เงื่อนไขเหล่านี้ คุณควรใช้การเชื่อมต่อซ้ำให้มากที่สุด เราขอแนะนำให้คุณตั้งค่าดังนี้

• ตั้งค่าระยะหมดเวลาในกรณีที่ไม่มีการใช้งานเป็น 2.5 นาที
• จำนวนคำขอสูงสุดในการเชื่อมต่อเป็นค่าสูงสุดที่เป็นไปได้
• จำนวนการเชื่อมต่อสูงสุดเป็นค่าสูงสุดที่ RAM รองรับได้ โดยตรวจสอบว่าจำนวนการเชื่อมต่อไม่ได้ใกล้เคียงกับค่านั้นมากเกินไป

เช่น ใน Apache การตั้งค่านี้อาจกำหนดให้ตั้งค่า KeepAliveTimeout เป็น 150, MaxKeepAliveRequests เป็น 0 และ MaxClients เป็นค่าที่ขึ้นอยู่กับประเภทเซิร์ฟเวอร์

เมื่อปรับลักษณะการทํางานของการเชื่อมต่อแล้ว คุณควรตรวจสอบด้วยว่าโค้ดผู้เสนอราคาไม่ได้ปิดการเชื่อมต่อโดยไม่จําเป็น ตัวอย่างเช่น หากคุณมีโค้ดฝั่งไคลเอ็นต์ที่แสดงการตอบกลับ "ไม่เสนอราคา" เริ่มต้นในกรณีที่เกิดข้อผิดพลาดหรือหมดเวลาในแบ็กเอนด์ ให้ตรวจสอบว่าโค้ดแสดงการตอบกลับโดยไม่ปิดการเชื่อมต่อ วิธีนี้จะช่วยหลีกเลี่ยงกรณีที่ผู้เสนอราคาทำงานหนักเกินไป การเชื่อมต่อเริ่มปิด และจำนวนการหมดเวลาเพิ่มขึ้น ซึ่งทำให้ผู้เสนอราคาถูกจำกัด

รักษาการเชื่อมต่อให้สมดุล

หาก Authorized Buyers เชื่อมต่อกับเซิร์ฟเวอร์ของผู้เสนอราคาผ่านพร็อกซีเซิร์ฟเวอร์ การเชื่อมต่ออาจไม่สมดุลเมื่อเวลาผ่านไป เนื่องจาก Authorized Buyers ทราบเฉพาะที่อยู่ IP ของพร็อกซีเซิร์ฟเวอร์ จึงไม่สามารถระบุได้ว่าเซิร์ฟเวอร์ของผู้เสนอราคาใดได้รับข้อความไฮไลต์แต่ละรายการ เมื่อเวลาผ่านไป เมื่อ Authorized Buyers สร้างและปิดการเชื่อมต่อ และเซิร์ฟเวอร์ของผู้เสนอราคาเริ่มทํางานอีกครั้ง จํานวนการเชื่อมต่อที่เชื่อมโยงกับแต่ละรายการอาจเปลี่ยนแปลงได้อย่างมาก

เมื่อมีการใช้การเชื่อมต่อบางรายการอย่างหนัก การเชื่อมต่ออื่นๆ ที่เปิดอยู่อาจไม่มีการใช้งานเป็นส่วนใหญ่เนื่องจากไม่จำเป็นต้องใช้ในขณะนั้น เมื่อการเข้าชมของผู้ซื้อที่ได้รับอนุญาตมีการเปลี่ยนแปลง การเชื่อมต่อที่ไม่ได้ใช้งานอาจกลายเป็นการเชื่อมต่อที่ใช้งานอยู่ และการเชื่อมต่อที่ใช้งานอยู่อาจกลายเป็นการเชื่อมต่อที่ไม่ได้ใช้งาน ซึ่งอาจทําให้เซิร์ฟเวอร์ของผู้เสนอราคาทำงานหนักไม่เท่ากันหากการเชื่อมต่อเป็นคลัสเตอร์ไม่ดี Google พยายามป้องกันปัญหานี้ด้วยการปิดการเชื่อมต่อทั้งหมดหลังจากได้รับคำขอ 10,000 รายการ เพื่อปรับสมดุลการเชื่อมต่อยอดนิยมโดยอัตโนมัติเมื่อเวลาผ่านไป หากยังพบว่าการเข้าชมไม่สมดุลในสภาพแวดล้อมของคุณ ให้ทำตามขั้นตอนเพิ่มเติมต่อไปนี้

1. เลือกแบ็กเอนด์ต่อคำขอแทนที่จะเลือกครั้งเดียวต่อการเชื่อมต่อหากคุณใช้พร็อกซีฝั่งไคลเอ็นต์
2. ระบุจํานวนคําขอสูงสุดต่อการเชื่อมต่อหากคุณใช้พร็อกซีการเชื่อมต่อผ่านฮาร์ดแวร์โหลดบาลานซ์หรือไฟร์วอลล์ และการแมปจะได้รับการแก้ไขเมื่อสร้างการเชื่อมต่อแล้ว โปรดทราบว่า Google ได้ระบุขีดจํากัดสูงสุดไว้ที่ 10,000 คำขอต่อการเชื่อมต่อแล้ว คุณจึงควรระบุค่าที่เข้มงวดขึ้นก็ต่อเมื่อยังพบว่าการเชื่อมต่อที่ร้อนจัดกระจุกตัวอยู่ในสภาพแวดล้อมของคุณ เช่น ใน Apache ให้ตั้งค่า MaxKeepAliveRequests เป็น 5,000
3. กําหนดค่าเซิร์ฟเวอร์ของผู้เสนอราคาเพื่อตรวจสอบอัตราการส่งคําขอและปิดการเชื่อมต่อบางส่วนของตนเองหากจัดการคําขอมากเกินไปอย่างต่อเนื่องเมื่อเทียบกับคู่แข่ง

จัดการกับการทำงานหนักเกินไปอย่างมีชั้นเชิง

โดยหลักการแล้ว ควรกำหนดโควต้าให้สูงพอเพื่อให้ผู้เสนอราคาได้รับคำขอทั้งหมดที่จัดการได้ แต่ไม่เกินจำนวนดังกล่าว ในทางปฏิบัติ การรักษาโควต้าให้อยู่ในระดับที่เหมาะสมเป็นงานที่ยาก และอาจเกิดการทำงานหนักเกินได้เนื่องด้วยสาเหตุหลายประการ เช่น แบ็กเอนด์หยุดทำงานในช่วงเวลาที่มีการใช้งานสูงสุด การเปลี่ยนแปลงการผสมการเข้าชมทำให้ต้องมีการประมวลผลคำขอแต่ละรายการมากขึ้น หรือการกำหนดค่าโควต้าสูงเกินไป ดังนั้น คุณควรพิจารณาว่าผู้เสนอราคาจะทํางานอย่างไรเมื่อมีการเข้าชมมากเกินไป

เราขอแนะนำให้เพิ่ม 15% ระหว่างจำนวนสูงสุด 7 วันกับ QPS ต่อสถานที่ซื้อขายเพื่อรองรับการเปลี่ยนแปลงการเข้าชมชั่วคราว (สูงสุด 1 สัปดาห์) ระหว่างภูมิภาคต่างๆ (โดยเฉพาะระหว่างเอเชียกับสหรัฐอเมริกาฝั่งตะวันตกและสหรัฐอเมริกาฝั่งตะวันออกกับสหรัฐอเมริกาฝั่งตะวันตก)

ในแง่ของลักษณะการทำงานภายใต้ภาระงานหนัก ผู้เสนอราคาจะแบ่งออกเป็น 3 หมวดหมู่กว้างๆ ดังนี้

ผู้เสนอราคาที่ "ตอบทุกรายการ"

แม้ว่าการติดตั้งใช้งานจะง่าย แต่ผู้เสนอราคารายนี้มีประสิทธิภาพต่ำที่สุดเมื่อใช้มากเกินไป แต่จะพยายามตอบกลับคําขอราคาเสนอทุกรายการที่เข้ามา ไม่ว่าในกรณีใดก็ตาม โดยจัดคิวคําขอที่ไม่สามารถแสดงได้ทันที สถานการณ์ที่ตามมามักจะมีลักษณะดังนี้

• เมื่ออัตราการส่งคำขอเพิ่มขึ้น เวลาในการตอบสนองของคำขอก็จะเพิ่มขึ้นด้วย จนกว่าคำขอทั้งหมดจะเริ่มหมดเวลา
• เวลาในการตอบสนองจะเพิ่มขึ้นอย่างรวดเร็วเมื่ออัตราข้อความไฮไลต์ใกล้ถึงจุดสูงสุด
• การจํากัดจะเริ่มทํางาน ซึ่งจะลดจํานวนข้อความไฮไลต์ที่อนุญาตลงอย่างมาก
• เวลาในการตอบสนองเริ่มดีขึ้น ทำให้การจำกัดลดลง
• รอบการเรียกเก็บเงินจะเริ่มขึ้นอีกครั้ง

กราฟเวลาในการตอบสนองของผู้เสนอราคารายนี้มีลักษณะเป็นลําดับฟันเลื่อยที่ชันมาก หรือคําขอที่อยู่ในคิวอาจทําให้เซิร์ฟเวอร์เริ่มใช้การแบ่งหน่วยความจําหรือทําอย่างอื่นที่ทําให้ระบบช้าลงในระยะยาว และเวลาในการตอบสนองจะไม่ดีขึ้นเลยจนกว่าเวลาที่มีการใช้งานสูงสุดจะสิ้นสุดลง ทําให้อัตราข้อความไฮไลต์ลดลงตลอดระยะเวลาที่มีการใช้งานสูงสุด ไม่ว่าในกรณีใด ระบบจะสร้างหรือตอบกลับข้อความไฮไลต์น้อยกว่าในกรณีที่กําหนดโควต้าเป็นค่าที่ต่ำลง

ผู้เสนอราคา "ข้อผิดพลาดเมื่อระบบทำงานหนักเกินไป"

ผู้เสนอราคารายนี้ยอมรับข้อความไฮไลต์สูงสุดตามอัตราที่กำหนด จากนั้นจะเริ่มแสดงข้อผิดพลาดสำหรับข้อความไฮไลต์บางรายการ ซึ่งอาจทำได้ผ่านระยะหมดเวลาภายใน การปิดใช้การจัดคิวการเชื่อมต่อ (ควบคุมโดย ListenBackLog ใน Apache) การใช้โหมดการยกเลิกแบบมีแนวโน้มเมื่อการใช้ประโยชน์หรือเวลาในการตอบสนองสูงเกินไป หรือกลไกอื่นๆ หาก Google ตรวจพบอัตราข้อผิดพลาดสูงกว่า 15% เราจะเริ่มจำกัด ผู้เสนอราคารายนี้ "ลดการสูญเสีย" ซึ่งช่วยให้ฟื้นตัวได้ทันทีเมื่ออัตราการส่งคำขอลดลง ต่างจากผู้เสนอราคาที่ "ตอบกลับทุกรายการ"

กราฟเวลาในการตอบสนองของผู้เสนอราคารายนี้มีลักษณะเป็นลําดับฟันเลื่อยที่ชันเล็กน้อยในระหว่างที่ระบบทำงานหนักเกินขีดจํากัด ซึ่งอยู่ในช่วงอัตราสูงสุดที่ยอมรับได้

ผู้เสนอราคา "ไม่เสนอราคาเมื่อมีการโหลดมากเกินไป"

ผู้เสนอราคารายนี้ยอมรับข้อความไฮไลต์สูงสุดตามอัตราที่กำหนด จากนั้นจะเริ่มแสดงการตอบกลับ "ไม่เสนอราคา" สำหรับข้อความไฮไลต์ที่เกินขีดจำกัด การดำเนินการนี้ทำได้หลายวิธี เช่นเดียวกับผู้เสนอราคา "ข้อผิดพลาดเมื่อระบบทำงานหนักเกินไป" สิ่งที่แตกต่างคือไม่มีการส่งสัญญาณกลับไปยัง Google เราจึงไม่เคยลดจำนวนข้อความไฮไลต์ ปริมาณงานที่มากเกินไปจะดูดซับโดยเครื่องส่วนหน้า ซึ่งจะอนุญาตให้เฉพาะการรับส่งข้อมูลที่สามารถจัดการได้เท่านั้นที่จะส่งต่อไปยังแบ็กเอนด์

กราฟเวลาในการตอบสนองสำหรับผู้เสนอราคารายนี้แสดงระดับที่ราบสูงซึ่ง (โดยจงใจ) หยุดทำงานควบคู่ไปกับอัตราการส่งคำขอในช่วงเวลาที่มีการใช้งานสูงสุด และเศษส่วนของคำตอบที่มีราคาเสนอก็ลดลงตามไปด้วย

เราขอแนะนําให้ใช้แนวทาง "ข้อผิดพลาดเมื่อระบบทำงานหนัก" ร่วมกับแนวทาง "ไม่เสนอราคาเมื่อระบบทำงานหนัก" ดังนี้

• จัดสรรทรัพยากรให้กับส่วนหน้ามากกว่าที่จำเป็นและตั้งค่าให้แสดงข้อผิดพลาดเมื่อทำงานหนักเกินไป เพื่อช่วยเพิ่มจำนวนการเชื่อมต่อที่ส่วนหน้าสามารถตอบสนองได้ในรูปแบบใดรูปแบบหนึ่ง
• เมื่อเกิดข้อผิดพลาดจากการรับส่งข้อมูลมากเกินไป เครื่องฝั่งหน้าเว็บจะใช้คำตอบ "ไม่เสนอราคา" สำเร็จรูปได้ และไม่จำเป็นต้องแยกวิเคราะห์คำขอเลย
• ใช้การตรวจสอบประสิทธิภาพการทํางานของแบ็กเอนด์ เช่น หากไม่มีแบ็กเอนด์ใดมีขีดจํากัดเพียงพอ ก็จะแสดงการตอบกลับ "ไม่เสนอราคา"

วิธีนี้ช่วยให้ระบบรองรับปริมาณงานที่มากเกินไปได้บางส่วนและช่วยให้แบ็กเอนด์มีโอกาสตอบกลับคำขอได้มากเท่าที่จะจัดการได้ คุณอาจมองเหตุการณ์นี้ว่า "ไม่เสนอราคาเมื่อระบบทำงานหนัก" โดยที่เครื่องฝั่งหน้าจะเปลี่ยนเป็น "ข้อผิดพลาดเมื่อระบบทำงานหนัก" เมื่อจํานวนคําขอสูงกว่าที่คาดไว้อย่างมาก

หากคุณมีผู้เสนอราคาที่ "ตอบสนองต่อทุกสิ่ง" ให้ลองเปลี่ยนเป็นผู้เสนอราคาที่ "เกิดข้อผิดพลาดเมื่อทำงานหนักเกินไป" โดยปรับลักษณะการเชื่อมต่อเพื่อไม่ให้ทำงานหนักเกินไป แม้ว่าวิธีนี้จะทำให้ระบบแสดงข้อผิดพลาดมากขึ้น แต่ก็ช่วยลดการหมดเวลาและป้องกันไม่ให้เซิร์ฟเวอร์อยู่ในสถานะที่ไม่สามารถตอบกลับคำขอใดๆ

พิจารณาการเพียร์

อีกวิธีในการลดเวลาในการตอบสนองหรือความแปรปรวนของเครือข่ายคือการเป็นพาร์ทเนอร์กับ Google การเพียร์ช่วยให้เพิ่มประสิทธิภาพเส้นทางที่การเข้าชมใช้เพื่อไปยังผู้เสนอราคาได้ ปลายทางการเชื่อมต่อจะยังคงเหมือนเดิม แต่ลิงก์กลางจะเปลี่ยนไป ดูรายละเอียดได้จากคู่มือการเพียร์ เหตุผลที่ควรใช้การเพียร์เป็นแนวทางปฏิบัติแนะนำสรุปได้ดังนี้

• ในอินเทอร์เน็ต การเลือกลิงก์การเปลี่ยนเส้นทางจะดำเนินการผ่าน "การกำหนดเส้นทางแบบฮอตพอต" เป็นหลัก ซึ่งจะค้นหาลิงก์ที่อยู่ใกล้ที่สุดนอกเครือข่ายของเราซึ่งสามารถนำแพ็กเก็ตไปยังปลายทางได้ และกำหนดเส้นทางแพ็กเก็ตผ่านลิงก์นั้น เมื่อการรับส่งข้อมูลผ่านแบ็กโบนน์บางส่วนที่เป็นของผู้ให้บริการที่เรามีการเชื่อมต่อการเพียร์จำนวนมาก ลิงก์ที่เลือกมีแนวโน้มที่จะอยู่ใกล้กับจุดเริ่มต้นของแพ็กเก็ต จากจุดนั้นไป เราไม่สามารถควบคุมเส้นทางของแพ็กเก็ตที่จะไปยังผู้เสนอราคาได้ ดังนั้นแพ็กเก็ตอาจถูกส่งต่อไปยังระบบอิสระ (เครือข่าย) อื่นๆ ระหว่างทาง

• ในทางตรงกันข้าม เมื่อมีข้อตกลงการเพียร์โดยตรง ระบบจะส่งแพ็กเก็ตผ่านลิงก์การเพียร์เสมอ ไม่ว่าแพ็กเก็ตจะมาจากที่ใด แพ็กเก็ตจะข้ามลิงก์ที่ Google เป็นเจ้าของหรือเช่าใช้จนกว่าจะถึงจุดเพียร์ที่แชร์ ซึ่งควรอยู่ใกล้กับตำแหน่งของผู้เสนอราคา การเดินทางกลับจะเริ่มต้นด้วยการข้ามไปยังเครือข่าย Google เป็นเวลาสั้นๆ และอยู่ในเครือข่าย Google ตลอดเส้นทางที่เหลือ การส่งข้อมูลส่วนใหญ่ผ่านโครงสร้างพื้นฐานที่ Google จัดการช่วยให้มั่นใจได้ว่าแพ็กเก็ตจะใช้เส้นทางที่มีเวลาในการตอบสนองต่ำและหลีกเลี่ยงความแปรปรวนที่อาจเกิดขึ้นได้

ส่ง DNS แบบคงที่

เราขอแนะนำให้ผู้ซื้อส่งผลลัพธ์ DNS แบบคงที่รายการเดียวไปยัง Google เสมอและไว้วางใจให้ Google จัดการการส่งข้อมูลการเข้าชม

แนวทางปฏิบัติทั่วไป 2 ข้อจากเซิร์ฟเวอร์ DNS ของผู้เสนอราคาเมื่อพยายามโหลดยอดสมดุลหรือจัดการความพร้อมใช้งานมีดังนี้

1. เซิร์ฟเวอร์ DNS จะแสดงที่อยู่ 1 รายการหรือชุดย่อยของที่อยู่เพื่อตอบกลับการค้นหา จากนั้นจะวนดูการตอบกลับนี้ในลักษณะใดลักษณะหนึ่ง
2. เซิร์ฟเวอร์ DNS จะตอบกลับด้วยชุดที่อยู่เดียวกันเสมอ แต่สลับลำดับของที่อยู่ในการตอบกลับ

เทคนิคแรกมีประสิทธิภาพในการกระจายภาระงานต่ำเนื่องจากมีการแคชจำนวนมากในหลายระดับของสแต็ก และการพยายามข้ามการแคชมีแนวโน้มที่จะไม่ได้ผลลัพธ์ที่ต้องการเช่นกัน เนื่องจาก Google จะเรียกเก็บค่าบริการจากเวลาในการแก้ไข DNS กับผู้เสนอราคา

เทคนิคที่ 2 ไม่ได้ใช้การกระจายโหลดเลย เนื่องจาก Google จะเลือกที่อยู่ IP จากรายการคำตอบ DNS แบบสุ่ม ดังนั้นลําดับในการตอบกลับจึงไม่มีความหมาย

หากผู้เสนอราคาทําการเปลี่ยนแปลง DNS ทาง Google จะยึดตาม TTL(Time-to-live) ที่ตั้งไว้ในระเบียน DNS แต่ช่วงเวลาในการรีเฟรชจะยังคงไม่แน่นอน