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

จัดการกับภาระงานที่หนักเกินไป

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

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

ในแง่ของพฤติกรรมที่มีภาระงานสูง ผู้เสนอราคาจะแบ่งออกเป็น 3 กลุ่ม หมวดหมู่:

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

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

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

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

"ข้อผิดพลาดเกี่ยวกับโอเวอร์โหลด" ผู้เสนอราคา

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

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

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

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

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

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

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

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

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

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

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

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"

โปรดทราบว่าคำขอคำสั่ง 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 แล้ว แต่ช่วงเวลาการรีเฟรชยังคงไม่แน่นอน