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