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

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

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

รักษาการเชื่อมต่อให้ดียิ่งขึ้น

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

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

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

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

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

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

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

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

รักษาสมดุลระหว่างการเชื่อมต่อ

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

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

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

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

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

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

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

ปุ่ม "ตอบกลับทุกอย่าง" ผู้เสนอราคา

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

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

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

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

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

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

ผู้เสนอราคา "ไม่เสนอราคาเมื่อเกิดภาระงานมากเกินไป"

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

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

เราขอแนะนำให้รวม "ข้อผิดพลาดเมื่อโอเวอร์โหลด" เข้าด้วยกัน ที่มีข้อความ "ไม่เสนอราคาเมื่อทำงานหนักเกินไป" ในลักษณะดังต่อไปนี้

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

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

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

ตอบสนองต่อคำสั่ง ping

การตรวจสอบว่าผู้เสนอราคาสามารถตอบกลับคําขอ ping แม้ว่าจะไม่ใช่การจัดการการเชื่อมต่อก็ตาม เป็นสิ่งที่สําคัญอย่างยิ่งสำหรับการแก้ไขข้อบกพร่อง Google ใช้คําขอ ping เพื่อตรวจสอบความถูกต้องและการแก้ไขข้อบกพร่องของสถานะผู้เสนอราคา ลักษณะการปิดการเชื่อมต่อ เวลาในการตอบสนอง และอื่นๆ คำขอ Ping มีรูปแบบดังนี้

id: "7xd2P2M7K32d7F7Y50p631"

{
  "id": "4YB27BCXimH5g7wB39nd3t"
}

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

โปรดทราบว่าคำขอ ping จะไม่มีตําแหน่งโฆษณา ตรงข้ามกับที่คุณคาดไว้ และตามที่อธิบายไว้อย่างละเอียดด้านบน คุณไม่ควรปิดการเชื่อมต่อหลังจากตอบกลับคำขอ ping

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

อีกวิธีหนึ่งที่จะช่วยลดเวลาในการตอบสนองหรือความแปรปรวนของเครือข่ายคือการจับคู่กับ 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 แต่ช่วงเวลาในการรีเฟรชจะยังคงไม่แน่นอน