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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שליחת DNS סטטי

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

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

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

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

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

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