אתם יכולים למדוד את הביצועים של Firebase Realtime Database באמצעות כלי פרופיל מסד הנתונים, שמוטמע ב-Firebase CLI. כלי הפרופיל יוצר יומן של כל הפעילות במסד הנתונים שלכם לאורך תקופה מסוימת, ואז מפיק דוח מפורט. אפשר להשתמש בדוח המפורט כדי לפתור בעיות בביצועי מסד הנתונים, לזהות אזורים בעייתיים ולצמצם את מספר השאילתות שלא נכללות באינדקס.
יצירת פרופיל
לפני שמתחילים ליצור פרופיל של Firebase Realtime Database, צריך לוודא שמשתמשים בגרסה העדכנית של Firebase CLI ושהיא אותחלה עבור מסד הנתונים והפרויקט שרוצים ליצור להם פרופיל. הערה: כדי ליצור פרופיל, צריך להיות בעלים או עורך של הפרויקט.
מריצים את הפקודה הבאה כדי להתחיל ליצור פרופיל של מסד הנתונים:
בפרופילר מוצגת הודעת סטטוס בזמן שהוא מתעד פעולות מהמסד נתונים ויוצר את הפרופיל.firebase database:profile
מקישים על Enter כדי להשלים את הפרופיל ולהציג את התוצאות.
פירוש התוצאות
כלי הפרופיל יוצר צבירה של הנתונים שהוא אוסף על הפעולות במסד הנתונים, ומציג את התוצאות בשלוש קטגוריות עיקריות: מהירות, רוחב פס ושאילתות לא מאונדקסות.
מהירות
בדוח המהירות נמדד זמן התגובה של השרת (באלפיות שנייה) לכל סוג פעולה. עם זאת, יכול להיות שהמהירות שנמדדת בדוח המהירות לא משקפת את המהירות שמשתמשי הקצה חווים בפועל. גורמים שונים, כולל תנאי הרשת, יכולים להוסיף זמן אחזור בצד הלקוח.
דוח המהירות כולל את המאפיינים הבאים:
- נתיב: הנתיב במסד הנתונים שבו התרחשו הפעולות. אם יש יותר מ-25 צמתי צאצא, הכלי לניתוח הביצועים מכווץ אותם לנתיב אב ומוסיף סמן
$wildcard
. יכול להיות שספריית הבסיס של מסד הנתונים תופיע בדוח, והיא תיוצג באמצעות קו נטוי/
. - ספירה: מספר הפעולות שהתרחשו בנתיב הנתון.
- מהירות ביצוע ממוצעת: הזמן הממוצע שנדרש לשרת כדי לבצע את הלוגיקה העסקית שנדרשת לטיפול בסוג הפעולה המסוים בנתיב הזה. מרווח הזמן שנמדד כאן מתחיל אחרי מרווח הזמן שנמדד על ידי המדד 'זמן ממוצע בהמתנה' שמתואר בהמשך.
- זמן ממוצע בהמתנה: משך הזמן הממוצע שבו בקשות נמצאות בתור לפני שהן מבוצעות. העיכוב הזה אופייני לכל הבקשות שמתחילות בצד הלקוח. זמן האחזור הכולל של הבקשה בצד השרת הוא בערך סכום הזמן שהבקשה ממתינה ומהירות הביצוע שלה.
- הגישה נדחתה: מספר הפעולות בנתיב הנתון שנחסמו על ידי כללי מסד הנתונים של Firebase במסד הנתונים שלכם.
דוח מהירות לפי סוג פעולה | |
---|---|
קריאת נתוני מהירות ההרצה | זמן התגובה של השרת לבקשות של לקוחות לקרוא נתונים ממסד הנתונים. זמן הקריאה בדרך כלל גדל בהתאם לכמות הנתונים שנקראים, אבל יכול להיות שגם קריאות קטנות יעוכבו בגלל אחזור מראש של נתונים מהמטמון. |
מהירות כתיבת הנתונים | זמן התגובה של השרת לבקשות של לקוחות לכתוב נתונים במסד הנתונים. לכתוב סולמות של זמן ביצוע עם כמות הנתונים שנכתבים. |
מהירות הביצוע של החיבור | זמן התגובה של השרת לבקשות ליצירת חיבור ללקוחות של מסד הנתונים. ההשהיה של בקשות החיבור נובעת בעיקר מניהול נתונים בצד השרת בזיכרון שקשור לניהול החיבורים. |
מהירות הביצוע של השידור | כמות הזמן שלוקח לשרת להפיץ נתונים ללקוחות שמקשיבים לנתיב הנתון לעדכונים בזמן אמת. המאפיין Count בדוח מהירות השידור מסכם את מספר השידורים שהתרחשו, ולא את מספר הלקוחות שקיבלו את המידע. לדוגמה, אם 10 לקוחות האזינו לנתיב מסוים, והשרת שידר עדכון לכל 10 הלקוחות, ספירת השידורים תשקף רק שידור אחד, למרות ש-10 לקוחות קיבלו את הנתונים. הנכס Permission Denied לא נכלל בדוח Broadcast Speed. |
רוחב פס
בדוח רוחב הפס אפשר לראות כמה נתונים נצרכים במסד הנתונים שלכם בפעולות נכנסות ויוצאות. עם זאת, לא כדאי להשתמש בדוח רוחב הפס כדי להעריך את החיוב, כי הוא לא כולל את רוחב הפס שמשמש לפעולות אחרות, כמו יצירת פרופיל של מסד הנתונים. בדוח רוחב הפס מוצגת הערכה של גודל המטען הייעודי (payload) של הנתונים שנצרכו על ידי פעולות קריאה, כתיבה ושידור אל מסד הנתונים וממנו. זהו כלי למדידת ביצועים, ולא כלי לחיזוי חיובים.
דוח רוחב הפס כולל את המאפיינים הבאים:
נתיב: הנתיב במסד הנתונים שבו התרחשו הפעולות. אם יש יותר מ-25 צמתי צאצא, כלי הפרופיל מכווץ אותם לנתיב אב.
סה"כ: סך הבייטים היוצאים או הנכנסים שנעשה בהם שימוש בכל הפעולות בנתיב הנתון.
ספירה: מספר הפעולות שהתרחשו בנתיב הנתון.
ממוצע: המספר הממוצע של בייטים שהורדו או הועלו בפעולות בנתיב הנתון (בייטים/כתיבה או בייטים/קריאה).
דוח רוחב פס | |
---|---|
בייטים שהורדו | נתונים שנצרכים באמצעות פעולות קריאה ושידור שנשלחות דרך ערכות ה-SDK של הלקוח ו-API ל-REST. |
בייטים שהועלו | נתונים שנצרכים דרך בקשות כתיבה שמגיעות לשרת מסד הנתונים. מחיקות מופיעות כפעולות כתיבה עם 0 בייט בקטע 'נכנסות'. |
שאילתות לא מאונדקסות
שאילתות לא מאונדקסות עלולות להיות יקרות, כי הלקוחות מורידים את כל הנתונים במיקום מסוים ואז מריצים עליהם שאילתות. השימוש ברוחב הפס יהיה גבוה יותר מהנדרש. כדאי לפתור כמה שיותר בעיות שקשורות לשאילתות שלא נוספו לאינדקס כדי לשפר את הביצועים של מסד הנתונים.
בדוח 'שאילתות לא מאונדקסות' מוצגים הנכסים הבאים:
- נתיב: הנתיב במסד הנתונים שבו התרחשו השאילתות שלא נכללו באינדקס.
- אינדקס: הכלל שצריך להוסיף כדי לפתור את הבעיה של שאילתות שלא נכללות באינדקס. מידע נוסף על הוספה לאינדקס זמין במאמר הוספת הנתונים לאינדקס.
- ספירה: מספר השאילתות שלא נוספו לאינדקס שהתרחשו בנתיב הנתון.
פרופילים מתקדמים
כדי לראות את כל הפעולות שמסד הנתונים מטפל בהן, משתמשים בדגל --raw
כשיוצרים פרופיל של מסד הנתונים, באופן הבא:
firebase database:profile --raw
הפלט הגולמי כולל גם מידע על הלקוח לכל פעולה, כמו מחרוזות userAgent
וכתובות IP. Firebase Realtime Databaseמידע נוסף על הפעולות השונות שמופיעות בפרופיל של Firebase Realtime Database
כלי הפרופיל: לא כלי לחיוב
אל תשתמשו בכלי ליצירת פרופילים כדי להעריך את עלות רוחב הפס. כלי הפרופיל נועד לספק תמונה כוללת של ביצועי מסד הנתונים, כדי לעזור לכם לעקוב אחרי פעולות ולפתור בעיות, ולא כדי להעריך את החיוב. הוא לא מתייחס לתנועת נתונים ברשת, אלא רק רושם הערכה של נתוני האפליקציה שנשלחים בתגובות.
ריכזנו כאן כמה דוגמאות נפוצות לתנועה ברשת שמחויבת על ידי Firebase ושלא נכללת בפרופיל מסד הנתונים שלכם:
- תקורה של פרוטוקול: נדרשת תעבורה נוספת בין השרת לבין הלקוחות כדי ליצור ולתחזק סשן. בהתאם לפרוטוקול הבסיסי, התנועה הזו עשויה לכלול: תקורה של פרוטוקול בזמן אמת של Firebase Realtime Database, תקורה של WebSocket ותקורה של כותרת HTTP. בכל פעם שנוצר חיבור, התקורה הזו, בשילוב עם תקורה של הצפנת SSL, תורמת לעלויות החיבור. למרות שבדרך כלל לא מדובר ברוחב פס גדול, הוא יכול להיות משמעותי אם המטען הייעודי (payload) שלכם קטן מאוד או אם אתם יוצרים חיבורים קצרים ותכופים.
- תקורה של הצפנת SSL: יש עלות שמשויכת לתקורה של הצפנת SSL שנדרשת לחיבורים מאובטחים. בממוצע, העלות הזו היא כ-3.5KB ללחיצת היד הראשונית, וכ-40B לכותרות של רשומות TLS בכל הודעה יוצאת. ברוב האפליקציות, זהו אחוז קטן מהחשבון. עם זאת, אם במקרה הספציפי שלכם נדרשים הרבה תהליכי לחיצת יד של SSL, יכול להיות שהערך הזה יהיה אחוז גבוה. לדוגמה, מכשירים שלא תומכים בכרטיסי TLS לסשן עשויים לדרוש מספר גדול של לחיצות ידיים לחיבור SSL.