כדי לעמוד במגבלות ההשהיה של שירות האוצרות בזמן אמת, מומלץ למקם את השרתים שלכם ליד האזורים ב-Google Cloud שסביר להניח שישלחו בקשות לפלחים למיקומים שמטרגטים. הקצאה והגדרה של DNS כך שתנועה שנשלחת לנקודת הקצה מאזור מסוים תנותב לשרת הקרוב ביותר.
בטבלה הבאה מפורטים האזורים ב-Google Cloud שבהם נעשה שימוש בסינון בזמן אמת, המיקום המשוער שלהם ודוגמאות למיקומים גיאוגרפיים שסביר להניח שיישלחו לשרתים שלכם ב-SegmentRequest מהאזורים האלה:
| אזור Google Cloud | מיקום אזורי | דוגמה למיקום יעד גיאוגרפי |
|---|---|---|
| us-east1 | דרום קרוליינה, ארצות הברית | צפון אמריקה (החוף המזרחי) |
| us-west1 | אורגון, ארצות הברית | צפון אמריקה (החוף המערבי) |
| us-central1 | איווה, ארצות הברית | צפון אמריקה (מרכז) |
| europe-west1 | בלגיה | אירופה |
| europe-west4 | אמסטרדם, הולנד | אירופה |
| asia-southeast1 | סינגפור | אסיה |
| asia-east1 | טאיוואן | אסיה |
שימוש בחיבור HTTP מתמשך כדי להפחית את זמן האחזור
כדי להקטין את זמן האחזור, Google ממליצה מאוד להגדיר את השילוב של העריכה בזמן אמת כך שישתמש בחיבור קבוע. אחרי שנוצר חיבור מתמשך, נקודת הקצה תשתמש מחדש בחיבורים במקום ליצור חיבור חדש לכל בקשת פלח נכנסת.
מיקום השרת
אפשר לצפות שרוב הבקשות לפלחים יישלחו מהאזור הכי קרוב למיקום של המשתמש, אבל Google לא מבטיחה שזה תמיד יהיה המצב. ככל שתמקמו שרתים קרוב למספר גדול יותר של אזורים, כך תוכלו לצפות לקבל קבוצה מלאה יותר של בקשות לפלחים עבור המיקומים המטורגטים שלכם. Google ממליצה למקם שרתים ליד קבוצת משנה של אזורים שמתאימים למיקומי היעד שלכם. לדוגמה, אפשר לקבל את רוב התנועה בצפון אמריקה אם ממקמים את השרתים קרוב לאזורים us-east1, us-west1 ו-us-central1.
המועד האחרון לשליחת תגובה על מקטע הוא 50 אלפיות השנייה.
המועד האחרון הזה כולל גם את זמן הרשת בין האזור לשרת שלכם, וגם את הזמן שנדרש לשרת שלכם כדי ליצור תגובה. מומלץ להגדיר לפחות 10ms של באפר לשינויים לא צפויים בהשהיית הרשת.
השלבים הבאים
- הפניה לפרוטוקול של בחירת תוכן בזמן אמת: מידע על המבנה של הבקשות והתשובות שמשמשות לבחירת תוכן בזמן אמת.
- ניתוח בקשות של 'בחירת תוכן בזמן אמת': מידע על ניתוח בקשות של 'בחירת תוכן בזמן אמת'.
- יצירת תשובות של עריכה בזמן אמת: כאן מוסבר איך ליצור תשובות של עריכה בזמן אמת.