מדריך אופטימיזציה

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

אבטחה

עיון בשיטות אבטחה מומלצות

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

שימוש במפתחות API לגישה לממשקי API של מפות Google

מפתחות API הם שיטת האימות המועדפת לגישה לממשקי API של מפות Google. נכון לעכשיו, השימוש במזהי הלקוח עדיין נתמך, אבל מפתחות API תומכים באמצעי בקרת אבטחה פרטניים יותר, ואפשר לכוונן אותם כך שיפעלו עם כתובות אינטרנט, כתובות IP וערכות SDK ספציפיות לניידים (Android ו-iOS). למידע על יצירה ואבטחה של מפתח API, תוכלו להיכנס לדף 'שימוש במפתח API' לכל API או SDK. (לדוגמה, עבור Maps JavaScript API, היכנסו לדף שימוש במפתח API).

ביצועים

שימוש בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) לטיפול בשגיאות

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

השהיה מעריכית לפני ניסיון חוזר (exponential backoff) שימושית ביותר לשגיאות ב-500 שניות. למידע נוסף, ראו את המאמר טיפול בקודים של סטטוס החזרות של HTTP.

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

שליחת בקשות לאינטראקציה של משתמשים לפי דרישה

יש לשלוח בקשות לממשקי API שכוללים אינטראקציה של משתמשים רק על פי דרישה. כלומר, צריך להמתין עד שמשתמש הקצה יבצע פעולה (כמו on-click) כדי להתחיל את הבקשה ל-API, ולהשתמש בתוצאות כדי לטעון מפה, להגדיר יעד או להציג מידע מתאים. גישה על פי דרישה מונעת בקשות מיותרות לממשקי ה-API, ומפחיתה את השימוש ב-API.

הימנעות מהצגת תוכן של שכבת-על כשהמפה זזה

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

הימנעות מפעולות אינטנסיביות בשיטות Draw

באופן כללי, מומלץ להימנע מפעולות אינטנסיביות ללא שרטוט בשיטה Draw(). לדוגמה, הימנעו מהפעולות הבאות בקוד ה-method של Draw():

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

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

שימוש בתמונות רשת עבור סמנים

כשמוסיפים סמנים כדי לזהות מיקום במפה, צריך להשתמש בתמונות בפורמט רשת, כמו תמונות בפורמט PNG. או JPG. מומלץ להימנע משימוש בתמונות Scalable Vector Graphics (SVG), מכיוון שעיבוד תמונות SVG עלול לגרום לעיכוב כשמתבצע שרטוט מחדש של המפה.

אופטימיזציה של סמנים

האופטימיזציה משפרת את הביצועים על ידי רינדור של סמנים רבים כאלמנט סטטי אחד. האפשרות הזו שימושית במקרים שבהם יש צורך במספר גדול של סמנים. כברירת מחדל, ה-API ל-JavaScript של מפות Google יחליט אם לבצע אופטימיזציה של סמן. כשיש הרבה סמנים, ה-API ל-JavaScript של מפות Google ינסה לעבד את הסמנים באמצעות אופטימיזציה. אי אפשר לבצע אופטימיזציה לכל הסמנים. במצבים מסוימים, יכול להיות ש-Maps JavaScript API יצטרך לעבד את הסמנים ללא אופטימיזציה. השבתת הרינדור הממוטב של קובצי GIF או PNG מונפשים, או כשצריך לעבד כל סמן כרכיב DOM נפרד.

יצירת אשכולות לניהול תצוגת הסמנים

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

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

צריכה

כדי לתכנן את התקציב ולשלוט בעלויות:

  • הגדירו התראת תקציב כדי לעקוב אחר הגידול בעלויות לקראת סכום מסוים. התקציב לא מגביל את השימוש ב-API, אלא רק כשהעלויות מתקרבות לסכום שצוין.
  • הגבילו את השימוש היומי ב-API כדי לנהל את העלויות של ממשקי API שניתנים לחיוב. הגדרת מכסות לבקשות ליום יכולה להגביל את העלויות. משתמשים במשוואה פשוטה כדי לקבוע את המכסה היומית, בהתאם לסכום שאתם רוצים להוציא: (עלות חודשית/מחיר לכל אחד)/30 = מכסה יומית (ל-API אחד). ההטמעה הספציפית עשויה להשתמש במספר ממשקי API הניתנים לחיוב, ולכן עליכם לשנות את המשוואה לפי הצורך. בכל חודש מוצע זיכוי של 200$לממשקי Google Maps API, אז מביאים זאת בחשבון.
  • שימוש במספר פרויקטים כדי לבודד את השימוש, לתעדף אותו ולעקוב אחריו. לדוגמה, נניח שאתם משתמשים באופן קבוע בממשקי ה-API של הפלטפורמה של מפות Google בבדיקות שלכם. כשיוצרים פרויקט נפרד לבדיקה – עם מכסות ומפתחות API משלו – אפשר לבדוק ביסודיות ולהימנע מהוצאות מיותרות.

ניהול הצריכה במפות Google

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

שימוש בתמונות סטטיות

בקשות שמשתמשות בתמונות דינמיות (מפות דינמיות ו-Street View דינמיים) עולות יותר מאשר במפות סטטיות וב-Street View סטטי. אם לא צופים אינטראקציות של משתמשים עם המפה או עם Street View (הגדלת התצוגה או הזזת התצוגה), כדאי להשתמש בגרסאות הסטטיות של ממשקי ה-API האלה.

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

שימוש ב-API של 'מפות Google' להטמעה

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

שימוש בערכות SDK של מפות לנייד עבור יישומים לנייד

עבור אפליקציות לנייד, בעת הצגת מפה, השתמשו ב-SDK של מפות Google ל-Android או ב-SDK של מפות ל-iOS. השתמשו ב-Maps Static API או ב-Maps JavaScript API כשאין צורך להשתמש בערכות SDK לנייד.

ניהול הצריכה ב'מסלולים'

הגבלת ציוני דרך ב-Directions API

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

שימוש באופטימיזציה של Directions API לניתוב אופטימלי

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

ארגומנט האופטימיזציה ממיין ציוני דרך כדי להבטיח ניתוב אופטימלי, כלומר חוויית הנסיעה מ-A ל-E היא חוויה טובה יותר (A-B-C-D-E) בהשוואה לרצף האקראי של מסלול שלא עבר אופטימיזציה (למשל A-D-B-C-E).

שימוש במודלים של תנועה בזמן אמת ב-Directions API וב- גיאוגרפי Matrix API

החיוב עבור בקשות של Directions API ושל גיאוגרפי Matrix API עם מודלים של תנועה בזמן אמת מתבצע בתעריף גבוה יותר. כדי להפעיל מודלים של תנועה בזמן אמת, צריך להגדיר את שעת היציאה ל-now.

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

שימוש במסלול שבו עברת ובכביש הקרוב ביותר כשנתוני ה-GPS לא מדויקים

התכונות של Maps Roads API, 'Route Traveled' ו-'הכביש הקרוב ביותר', נכללות ברמה המתקדמת והחיוב מתבצע בתעריף גבוה יותר. כדאי להשתמש בתכונות האלה כאשר נתוני ה-GPS לא מדויקים ו-Roads API יכול לעזור לקבוע את הכביש הנכון. מגבלות מהירות, תכונה נוספת ב-Roads API, שזמינה רק ללקוחות של מעקב אחר נכסים.

מיקומים למגבלת מהירות הדגימה במרווחי זמן של 5 עד 15 דקות

כדי לצמצם את נפח הקריאות ל-Maps Roads API Speed Limit, כדאי לדגום את מיקומי הנכסים במרווחים של 5 עד 15 דקות. הערך המדויק תלוי במהירות שבה הנכס מתקדם. אם הנכס נייח, מספיק להשתמש בדגימה אחת של מיקום. אין צורך לבצע שיחות מרובות.

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

ניהול הצריכה ב'מקומות'

אופטימיזציה של הטמעות השלמה אוטומטית של מקומות

כדי לייעל את עלות השימוש בהשלמה אוטומטית של מקומות:

  • להשתמש במסכות של שדות בווידג'טים להשלמה אוטומטית של JavaScript, Android ו-iOS כדי להחזיר רק את השדות של נתוני המקום שדרושים לכם.

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

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

החזרת נתונים לשדות ספציפיים בבקשות 'פרטי מקום' ו'חיפוש מקום'

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

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

הפחתת עלויות באמצעות שימוש ב-Geocoding API

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

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

איך פועלות המכסות בפלטפורמה של מפות Google

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

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

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

ממשקי ה-API של GMP שכוללים את אפשרות האכיפה הזו לשנייה הם Directions API, ההסמכה Matrix API, Elevation API, Geocoding API, Places API ו-Roads API.

הערכת העלויות של כל מוצר GMP API, על סמך נפח הבקשות הכולל.