แนวทางปฏิบัติแนะนำสำหรับแอปพลิเคชัน 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 รายการ เพื่อปรับสมดุลระหว่างการเชื่อมต่อ Hot โดยอัตโนมัติเมื่อเวลาผ่านไป หากยังพบว่าการเข้าชมไม่สมดุลกันในระบบ คุณสามารถดำเนินการตามขั้นตอนต่อไปนี้ได้อีก

1. หากคุณใช้พร็อกซีฟรอนท์เอนด์ ให้เลือกแบ็กเอนด์ตามคำขอแทน 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 จะมีรูปแบบดังนี้

Google

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

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

โปรโตคอล OpenRTB

id: "7xd2P2M7K32d7F7Y50p631"

โปรดทราบว่าคำขอคำสั่ง ping ของ OpenRTB จะไม่มีสัญญาณ is_ping เนื่องจากโมเดล OpenRTB ไม่มีช่อง ping ระบบจึงส่งคำขอ ping เฉพาะกิจ ซึ่งเป็น BidRequest ที่มีเฉพาะรหัสเท่านั้น ผู้เสนอราคาไม่จำเป็นต้องมีการจัดการพิเศษสำหรับเรื่องนี้ ลักษณะการทำงานปกติจะส่งคืนการตอบกลับโดยไม่มีราคาเสนอ

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

ลองเพียร์

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

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

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

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

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

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

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

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

เทคนิคที่ 2 ไม่ทำให้เกิดการจัดสรรภาระงานเลย เนื่องจาก Google สุ่มเลือกที่อยู่ IP จากรายการการตอบกลับของ DNS เพื่อให้ลำดับในการตอบสนองไม่มีความสำคัญ

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