כדי למדוד את הביצועים של Firebase Realtime Database, אתם יכולים להשתמש בכלי ליצירת פרופילים של מסדי נתונים, שמובנה בממשק שורת הפקודה של Firebase. כלי הפרופיילר מתעד את כל הפעילות במסד הנתונים לאורך תקופה מסוימת, ואז יוצר דוח מפורט. אתם יכולים להשתמש בדוח המפורט כדי לפתור בעיות בביצועים של מסד הנתונים, לזהות אזורים בעייתיים ולצמצם את מספר השאילתות שלא נוספו לאינדקס.
יצירת פרופיל
לפני שמתחילים ליצור פרופיל של Firebase Realtime Database, חשוב לוודא שמשתמשים בגרסה העדכנית של ה-CLI של Firebase ושהפעלתם אותו במסד הנתונים ובפרויקט שאתם רוצים ליצור להם פרופיל. שימו לב שאתם צריכים להיות בעלי הרשאת עריכה או בעלים של הפרויקט כדי ליצור פרופיל.
כדי להתחיל ליצור פרופיל של מסד הנתונים, מריצים את הפקודה הבאה:
firebase database:profile
מקישים על Enter כדי להשלים את הפרופיל ולהציג את התוצאות.
פירוש התוצאות
כלי הפרופיילינג צובר את הנתונים שנאספו על הפעולות של מסד הנתונים, ומציג את התוצאות בשלוש קטגוריות עיקריות: מהירות, רוחב פס ושאילתות ללא אינדקס.
מהירות
דוח המהירות מודד את זמן התגובה של השרת (באלפיות השנייה) לכל סוג פעולה. עם זאת, יכול להיות שהמהירות שנמדדת בדוח המהירות לא משקפת את המהירות שמשתמשי הקצה חווים בפועל. גורמים שונים, כולל תנאי הרשת, יכולים להוסיף זמן אחזור בצד הלקוח.
דוח המהירות כולל את המאפיינים הבאים:
- נתיב: הנתיב במסד הנתונים שבו בוצעו הפעולות. אם יש יותר מ-25 צומתי צאצא, הכלי לניתוח הביצועים מכווץ אותם לנתיב הורה ומוסיף את הסימון
$wildcard. יכול להיות שבדוח תופיע תיקיית השורש של מסד הנתונים, שמיוצגת על ידי קו נטוי/. - ספירה: מספר הפעולות שהתרחשו בנתיב הנתון.
- מהירות ביצוע ממוצעת: הזמן הממוצע שלוקח לשרת לבצע את הלוגיקה העסקית שנדרשת כדי לטפל בסוג הפעולה הספציפי בנתיב הזה. מרווח הזמן שנמדד כאן מתחיל אחרי מרווח הזמן שנמדד ב "זמן המתנה ממוצע" שמתואר בהמשך.
- זמן המתנה ממוצע: משך הזמן הממוצע שבקשות ממתינות בתור לפני שהן מבוצעות. העיכוב הזה נפוץ בכל הבקשות שמופעלות על ידי הלקוח. זמן האחזור הכולל של בקשה בצד השרת הוא בערך הסכום של זמן ההמתנה של הבקשה ומהירות הביצוע.
- Permission Denied: מספר הפעולות בנתיב הנתון שנחסמו על ידי כללי מסד הנתונים של Firebase במסד הנתונים שלכם.
| דוח מהירות לפי סוג הפעולה | |
|---|---|
| מהירות קריאת הנתונים | זמן התגובה של השרת לבקשות של לקוחות לקרוא נתונים ממסד הנתונים. זמן הביצוע של פעולת קריאה בדרך כלל משתנה בהתאם לכמות הנתונים שנקראים, אבל גם פעולות קריאה קטנות יכולות להתעכב בגלל אחזור מראש של מטמון. |
| מהירות ביצוע הכתיבה | זמן התגובה של השרת לבקשות של לקוחות לכתיבת נתונים במסד הנתונים. משך הזמן של פעולת הכתיבה משתנה בהתאם לכמות הנתונים שנכתבים. |
| מהירות ביצוע החיבור | זמן התגובה של השרת לבקשות ליצירת לקוחות של מסד נתונים. זמן האחזור של בקשות החיבור מושפע בעיקר מניהול החיבורים בזיכרון בצד השרת. |
| מהירות הביצוע של השידור | משך הזמן שלוקח לשרת להפיץ נתונים ללקוחות שמאזינים לנתיב הנתון לקבלת עדכונים בזמן אמת. המאפיין Count ב-Broadcast Speed Report צובר את מספר השידורים שהתרחשו, ולא את מספר הלקוחות שקיבלו את המידע. לדוגמה, אם 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, תקורה של WebSocket ותקורה של כותרת HTTP. בכל פעם שנוצר חיבור, התקורה הזו, בשילוב עם תקורה של הצפנת SSL, תורמת לעלויות החיבור. בדרך כלל לא מדובר ברוחב פס גדול, אבל הוא יכול להיות משמעותי אם המטענים הייעודיים קטנים מאוד או אם אתם יוצרים חיבורים קצרים לעיתים קרובות.
- תקורה של הצפנת SSL: יש עלות שקשורה לתקורה של הצפנת SSL שנדרשת לחיבורים מאובטחים. בממוצע, העלות הזו היא בערך 3.5KB ללחיצת היד הראשונית, ובערך 40B לכותרות של רשומות TLS בכל הודעה יוצאת. ברוב האפליקציות, מדובר באחוז קטן מהחשבון. עם זאת, האחוז הזה יכול להיות גדול יותר אם במקרה הספציפי שלכם נדרשות הרבה לחיצות ידיים של SSL. לדוגמה, מכשירים שלא תומכים בכרטיסי סשן של TLS עשויים לדרוש מספר גדול של לחיצות ידיים (handshakes) של חיבורי SSL.