שיטות מומלצות לאפליקציות לבידינג בזמן אמת (RTB)

במדריך הזה מפורטות שיטות מומלצות שכדאי להביא בחשבון כשמפתחים אפליקציות בהתאם לפרוטוקול RTB.

ניהול החיבורים

שמירה על החיבורים

יצירת חיבור חדש מגדילה את זמן האחזור וממושכת הרבה יותר זמן בשני הקצוות מאשר שימוש חוזר בחשבון קיים. על ידי סגירה של פחות אפשר לצמצם את מספר החיבורים שצריך לפתוח שוב.

ראשית, כל חיבור חדש דורש הלוך ושוב נוסף ברשת ליצור. מכיוון שאנחנו יוצרים חיבורים על פי דרישה, למועד היעד בפועל של הבקשה הראשונה בחיבור יש טווח קצר יותר, ויש סיכוי גבוה יותר שהזמן יפוג לפני שהיא תתבצע בהשוואה לבקשות הבאות. כל עוד זמן קצוב לתפוגה מגדיל את שיעור השגיאות, דבר שעלול להוביל למגיש הצעות המחיר שעובר ויסות נתונים (throttle).

שנית, שרתי אינטרנט רבים יוצרים שרשור עבודה ייעודי לכל חיבור שנוצר. כלומר, כדי לסגור את החיבור וליצור אותו מחדש, השרת לכבות את השרשור ולמחוק אותו, להקצות שרשור חדש, לאפשר הרצה שלו יוצר את מצב החיבור לפני שמסיימים לעבד את הבקשה. זה הרבה של תקורה מיותרת.

הימנעות מסגירת חיבורים

מתחילים בהתאמת התנהגות החיבור. רוב הגדרות ברירת המחדל של השרת מותאמות לסביבות עם מספר גדול של לקוחות, שכל אחד מהם שולח מספר קטן של בקשות. לעומת זאת, ב-RTB, מאגר קטן של מכונות שולח בקשות בשם מספר גדול יחסית של דפדפנים. מתחת ולכן הגיוני להשתמש שוב בחיבורים כמה שיותר פעמים. מומלץ להגדיר את הפרמטרים הבאים:

• הזמן הקצוב לתפוגה של חוסר פעילות הוא 2.5 דקות.
• המספר המקסימלי של בקשות בחיבור לרמה הגבוהה ביותר בערך האפשרי.
• מספר החיבורים המקסימלי הוא הערך הגבוה ביותר שזיכרון ה-RAM יכול להכיל, תוך הקפדה על כך שמספר החיבורים לא יתקרב לערך הזה יותר מדי.

לדוגמה ב-Apache, הפעולה הזו כרוכה בהגדרה KeepAliveTimeout עד 150, MaxKeepAliveRequests עד אפס, ו-MaxClients לערך שתלוי בסוג השרת.

אחרי שתשנו את התנהגות החיבור, עליכם לוודא שקוד הבידינג לא סוגר חיבורים ללא צורך. לדוגמה, אם יש לך ממשק קצה שמחזיר את ערך ברירת המחדל 'ללא הצעת מחיר' תגובה במקרה של קצה עורפי שגיאות או זמנים קצובים לתפוגה, ודאו שהקוד מחזיר את התגובה שלו בלי לסגור את חיבור כזה. כך תוכלו להימנע ממצב שבו אם מגיש הצעות המחיר שלכם עומס יתר, החיבורים מתחילים להיסגר ומספר הזמן הקצוב לתפוגה גדל, שגורמת לויסות נתונים (throttle) של מגיש הצעות המחיר.

איך שומרים על איזון החיבורים

אם מערכת Authorized Buyers מתחברת לשרתים של המגישים באמצעות שרת proxy, יכול להיות שהאיזון בחיבורים ישתנה עם הזמן כי מערכת Authorized Buyers יודעת רק את כתובת ה-IP של שרת ה-proxy, ולכן היא לא יכולה לקבוע איזה שרת של מגיש הצעות מחיר מקבל כל קריאה. עם הזמן, כאשר חשבונות ה-Authorized Buyers יוצרים חיבורים וסוגרים אותם, והשרתים של המגישים מתחילים לפעול מחדש, מספר החיבורים שממופים לכל אחד מהם עשוי להשתנות מאוד.

כשיש שימוש רב בחיבורים מסוימים, חיבורים פתוחים אחרים עשויים להישאר ברוב הזמן במצב חוסר פעילות כי אין צורך בהם כרגע. כשהתנועה של הקונים המורשים משתנה, חיבורים במצב חוסר פעילות יכולים להפוך לחיבורים פעילים, וחיבורים פעילים יכולים להפוך לחיבורים במצב חוסר פעילות. אם החיבורים לא מקובצים בצורה יעילה, הן עלולות לגרום לעומסים לא אחידים על שרתי הבידינג. Google מנסה למנוע זאת על ידי סגירת כל החיבורים אחרי 10,000 בקשות, כדי לאזן מחדש את החום באופן אוטומטי לאורך זמן. אם עדיין יש חוסר איזון בתנועה בסביבה שלכם, תוכלו לבצע את הפעולות הבאות:

1. יש לבחור את הקצה העורפי לכל בקשה ולא פעם אחת לכל חיבור אם משתמשים בשרתי proxy בחזית.
2. צריך לציין מספר מקסימלי של בקשות לכל חיבור אם אתם משתמשים בשרת proxy לחיבורים דרך מאזן עומסים או חומת אש בחומרה, והמיפוי קבוע אחרי שהחיבורים נוצרים. חשוב לזכור ש-Google כבר מציינת מגבלה עליונה של 10,000 בקשות לכל חיבור, כך שצריך לספק ערך מחמיר יותר רק אם עדיין מוצאים קשרים חמים שמצטברים בסביבה. ב-Apache, לדוגמה, קביעת הערך של MaxKeepAliveRequests כ-5,000
3. להגדיר השרתים של מגיש הצעות המחיר כדי לעקוב אחרי קצב הבקשות שלו ולסגור חלק של החיבורים שלהם, אם הם מטפלים בעקביות ביותר מדי בקשות בהשוואה לעמיתים שלהם.

טיפול יעיל בחיבור יתר

באופן אידיאלי, המכסות צריכות להיות גבוהות מספיק כדי שהבידינג יוכל לקבל את כל הבקשות שהוא יכול לטפל בהן, אבל לא יותר מזה. בפועל, קשה לשמור על המכסות ברמות אופטימליות, ועומס יתר קורה מסיבות שונות: צד לקוח פנימי מושבת בשעות השיא, שינוי בתערובת התנועה כך שנדרש יותר עיבוד לכל בקשה, או שהערך של המכסה מוגדר גבוה מדי. לכן כדאי להביא בחשבון את אופן הפעולה של מגיש הצעות המחיר מגיעה יותר מדי תנועה.

כדי להתאים לשינויים זמניים בתנועה (עד שבוע) בין אזורים (במיוחד בין אסיה למערב ארה"ב ולמזרח ארה"ב ולמערב ארה"ב), אנחנו ממליצים על ריפוד של 15% בין השיא ב-7 ימים לבין ה-QPS לכל מסחר מיקום.

מבחינת ההתנהגות בעומסים כבדים, מגישי הצעות המחיר משתייכים לשלוש קטגוריות קטגוריות:

המגיש הצעות המחיר מסוג 'תגובה לכל'

אומנם קל להטמיע את מגיש הצעות המחיר הזה, אבל הוא ייש את הגרוע ביותר כאשר עומס יתר. היא פשוט מנסה להגיב לכל בקשת הצעת מחיר שמתקבלת, ללא קשר למצב, ומוסיפה לתור בקשות שלא ניתן להציג באופן מיידי. התרחיש שמתרחש בדרך כלל נראה כך:

• ככל שקצב הבקשות גדל, כך גם זמני האחזור של הבקשות עולים, עד שכל הבקשות התחלת זמן קצוב לתפוגה
• זמני האחזור עולים בצורה חדה כאשר שיעורי הצגת המודעות של התוספים האלה מתקרבים לשיא
• ויסות הנתונים (throttle) בעיטות, הקטנת מספר נכסי היתרונות המרכזיים המותרים באופן חד
• זמן האחזור מתחיל להתאושש, מה שמוביל לצמצום של ויסות הנתונים
• המחזור מתחיל שוב.

תרשים זמן האחזור של המגיש הזה דומה לדפוס תלול מאוד של שיני מסור. לחלופין, בקשות בהמתנה גורמות לשרת להתחיל לעבור לדפים או לבצע פעולה אחרת שגורמת להאטה ארוכת טווח, וזמן האחזור לא מתאוששים עד שזמני השיא יסתיימו, מה שמוביל ליתרונות מרכזיים מדכאים במהלך כל תקופת השיא. בכל מקרה, יש פחות יתרונות מרכזיים, או יותר מאשר אילו הייתם פשוט מגדירים את המכסה לערך נמוך יותר.

"שגיאה בעומס יתר" מגיש הצעות המחיר

המשתתף במכרז הזה מקבל קריאות לפעולה עד שיעור מסוים, ואז מתחיל להחזיר שגיאות לגבי חלק מהקריאות לפעולה. אפשר לעשות זאת באמצעות זמנים קצובים לתפוגה פנימיים, השבתה לתורי חיבור (נשלט על ידי ListenBackLog ב-Apache), הטמעת מצב של ירידה הסתברותית כשהשימוש או זמן האחזור מתעדכנים גבוהה או מנגנון אחר. אם Google תזהה שיעור שגיאות גבוה מ-15%, נתחיל לבצע ויסות נתונים. בניגוד למגיש הצעות המחיר שמגיב לכל בקשה, מגיש הצעות המחיר הזה 'מקטין את ההפסדים', וכך הוא יכול להתאושש באופן מיידי כששיעורי הבקשות יורדים.

התרשים של זמן האחזור של המגיש הזה דומה לדפוס של שיניים שטוחות במהלך עומסי יתר, שמתמקדים סביב הקצב המרבי הקביל.

האפשרות 'ללא הגשת הצעת מחיר בעומס יתר' מגיש הצעות המחיר

המשתתף במכרז הזה מקבל מודעות קריאה לפעולה עד שיעור מסוים, ואז מתחיל להחזיר תשובות מסוג 'no-bid' לכל עומס יתר. בדומה למגיש הצעות המחיר מסוג 'שגיאה בזמן עומס', אפשר להטמיע את הפתרון הזה בכמה דרכים. מה ששונה כאן הוא שלא אותות מוחזרים ל-Google, כך שאנחנו אף פעם לא מווסתים על סמך נכסי יתרונות מרכזיים. עומס יתר נספג במכונות הקצה, שמאפשרות רק לתנועה שהן יכולות לטפל בה להמשיך לחלק העורפי.

בתרשים של זמן האחזור של המשתתף במכרז הזה מוצגת רמה יציבה (מלאכותית) שמפסיקה להתאים לשיעור הבקשות בשעות השיא, וירידה תואמת בחלק מהתשובות שמכילות הצעת מחיר.

מומלץ לשלב את הבעיה 'שגיאה בעומס יתר' עם הכיתוב 'ללא הצעת מחיר בעומס יתר' באופן הבא:

• כדאי להקצות יותר משאבים לקצוות הקדמיים ולהגדיר אותם כך שיופיעו שגיאות במקרה של עומס יתר, כדי למקסם את מספר החיבורים שהם יכולים להגיב אליהם בצורה כלשהי.
• כאשר מופיעות שגיאות בעומס יתר, מכונות הקצה הקדמי יכולות להשתמש ב"ללא הצעת מחיר" מוכנה מראש ולא צריך לנתח את הבקשה בכלל.
• מטמיעים בדיקת תקינות של הקצוות העורפיים, כך שאם לאף אחד מהם אין מספיק קיבולת פנויה, הם יחזירו תשובה מסוג 'no-bid'.

כך ניתן לספוג עומס יתר מסוים ולתת לקצוות העורפיים להגיב בדיוק למספר הבקשות המקסימלי שהם יכולים לטפל בהן. אפשר לחשוב על זה כ"ללא הצעת מחיר בעומס יתר" עם מכונות חזיתיות שחוזרות למצב של שגיאה עומס יתר" כאשר מספר הבקשות גבוה באופן משמעותי מהצפוי.

אם יש לכם בידינג מסוג 'תגובה לכל בקשה', כדאי לשקול להפוך אותו לבידינג מסוג 'שגיאה בזמן עומס יתר' על ידי שינוי התנהגות החיבור כך שהוא יידחה עומס יתר. אומנם זה גורם ליותר שגיאות, אבל מפחית את הזמן הקצוב לתפוגה ומונע מהשרת להיכנס למצב שבו הם לא יכולים להגיב לבקשות.

תשובה לפינגים

ודאו שמגיש הצעות המחיר יכול להגיב לבקשות לפינג בלי להיות חיבור כשלעצמם, חשוב באופן מפתיע לניפוי באגים. Google משתמשת בפינג בקשות לבדיקת שפיות ולניפוי באגים בסטטוס מגיש הצעות המחיר, סגירת החיבור התנהגותית, זמן אחזור ועוד. בקשות 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.

כדאי לשקול קישור בין רשתות שכנות (peering)

דרך נוספת לצמצם את זמן האחזור או השונות של הרשת היא ליצור קישור ל-Google. קישור בין רשתות שכנות (peering) עוזר לבצע אופטימיזציה של נתיב התנועה כדי להגיע למגיש הצעות המחיר. נקודות הקצה של החיבור לא ישתנו, אבל קישורי הביניים משתנים. לצפייה לפרטים נוספים, אפשר לעיין במדריך לקישור בין רשתות שכנות (peering). הסיבה לכך ששימוש ב-peering נחשב לשיטה מומלצת היא:

• באינטרנט, קישורי מעבר נבחרים בעיקר באמצעות 'ניתוב של תפוח רותח', שמוצא את הקישור הקרוב ביותר מחוץ לרשת שלנו שיכול להעביר חבילה ליעד שלה, ומנתב את החבילה דרך הקישור הזה. כשתנועה עוברת בקטע של ציר עיבוד נתונים בבעלות ספק שיש לנו איתו הרבה חיבורי peering, סביר להניח שהקישור שנבחר יהיה קרוב למקום שבו החבילה מתחילה. מעבר לנקודה הזו, אין לנו שליטה על המסלול של החבילה. מותאמות למגיש הצעות המחיר, כך שיכול להיות שיוחזרו למערכות אוטונומיות אחרות (רשתות) לאורך הדרך.

• לעומת זאת, כשקיים הסכם קישור ישיר בין רשתות שכנות (peering), המנות נשלחות תמיד לאורך קישור קישור בין רשתות שכנות (peering). לא משנה מאיפה מגיעה החבילה, ש-Google מחזיקה בקישורים שבבעלותה או ש-Google חוכרת עד שהיא מגיעה נקודת קישור בין רשתות שכנות (peering), שצריכה להיות קרובה למיקום של מגיש הצעות המחיר. הנסיעה הפוכה מתחילה בקפיצה קצרה לרשת Google, וממשיכה ברשת Google עד לסיום. העובדה שרוב המסלול מתבצע בתשתית בניהול Google מבטיחה שהחבילה תעבור במסלול עם זמן אחזור קצר, ומונעת תנודות פוטנציאליות רבות.

שליחת DNS סטטי

אנחנו ממליצים לקונים לשלוח ל-Google תוצאת DNS סטטית אחת תמיד, ולהסתמך על ב-Google כדי לטפל בתנועת הגולשים.

הנה שתי שיטות נפוצות שמבוססות על מגישי הצעות המחיר שרתי DNS כשמנסים לטעון יתרה או ניהול הזמינות:

1. שרת ה-DNS מוסר כתובת אחת או קבוצת משנה של כתובות בתגובה לשאילתה, ולאחר מכן לעבור על התשובה הזו בצורה מסוימת.
2. שרת ה-DNS תמיד משיב עם אותה קבוצת כתובות, אבל הוא מחליף את הסדר של הכתובות בתשובה.

השיטה הראשונה לא יעילה במאזן העומסים כי יש הרבה אחסון במטמון בכמה רמות בסטאק, וגם ניסיונות לעקוף את האחסון במטמון לא צפויים להניב את התוצאות הרצויות, כי Google מחייבת את המגיש על זמן פתרון ה-DNS.

השיטה השנייה לא משיגה איזון עומסים בכלל, כי Google בוחרת באקראי כתובת IP מרשימת התגובות של DNS, כך שהסדר אין חשיבות.

אם מגיש הצעות מחיר מבצע שינוי DNS, Google תפעל בהתאם ל-TTL(אורך החיים) שהוגדר שהוגדר ברשומות ה-DNS, אבל מרווח הרענון עדיין לא ודאי.