הסיפור מתחיל תמיד אותו דבר: אפליקציה שעבדה מצוין נהייתה איטית, המשתמשים מתלוננים, ומישהו כבר הכין הצעת מחיר לשרת חזק יותר. עצרו רגע לפני החתימה. מהניסיון שלנו, ברוב מקרי האיטיות ב-Qlik Sense הבעיה אינה בברזל אלא בתכנון: במודל הנתונים, בביטויים או בתהליך הטעינה. שרת חדש במקרים כאלה קונה שקט לחצי שנה, ואז הבעיה חוזרת, גדולה יותר.
הנה סדר האבחון שאנחנו עובדים לפיו, מהזול לַיקר.
קודם כול: להבין מה בדיוק איטי
"האפליקציה איטית" זה לא אבחון. צריך להפריד בין שלושה מצבים שונים לגמרי: פתיחת האפליקציה איטית, תגובה איטית ללחיצות וסינונים, או טעינת נתונים (Reload) שמתארכת. לכל אחד גורמים אחרים ותרופות אחרות, ובלבול ביניהם הוא הדרך הבטוחה לפתרון הלא נכון.
תחנה 1: מודל הנתונים
זה החשוד המרכזי, וכמעט תמיד בצדק. הדברים שמכבידים ביותר:
- מפתחות סינתטיים ולולאות. Qlik מייצר אותם בשקט כששתי טבלאות חולקות יותר משדה משותף אחד, והם זוללים זיכרון ומבלבלים תוצאות. אם יש כאלה במודל, זו העדיפות הראשונה.
- טבלאות רחבות מדי. עשרות שדות שנטענו "ליתר ביטחון" ואיש לא משתמש בהם. כל שדה מיותר עולה זיכרון, במיוחד שדות עם ערכים ייחודיים רבים.
- קרדינליות גבוהה בלי צורך. חותמות זמן מלאות כשדה מקושר הן דוגמה קלאסית: פיצול לתאריך ולשעה מקטין את המודל דרמטית.
- ריבוי טבלאות בשרשרת. ככל שהמסלול בין העובדות למאפיינים ארוך יותר, החישובים כבדים יותר. לרוב עדיף מודל כוכב פשוט.
תחנה 2: הביטויים בממשק
אם האפליקציה נפתחת מהר אבל נחנקת בכל לחיצה, החשד עובר לביטויים:
- שרשראות IF מקוננות בתוך מדדים, במקום דגלים שחושבו מראש בסקריפט. ההבדל בביצועים יכול להיות של סדרי גודל.
- Count Distinct על שדות ענקיים בכל רענון של כל אובייקט.
- AGGR מסובכים שבנו כדי לפתור בעיה שהייתה צריכה להיפתר במודל.
כלל אצבע ששווה לאמץ: כל תנאי עסקי קבוע ("לקוח פעיל", "הזמנה באיחור") צריך להיות שדה דגל שמחושב פעם אחת בטעינה, לא ביטוי שמחושב מיליון פעמים במסך.
תחנה 3: תהליך הטעינה
Reload ארוך הוא בעיה בפני עצמה, וגם סימן לארכיטקטורה חסרה. אם כל אפליקציה טוענת הכול ישירות מהמקור, כל לילה, אתם משלמים שוב ושוב על אותה עבודה. שכבות QVD מסודרות, עם טעינה אינקרמנטלית לטבלאות הגדולות, מקצרות טעינות משעות לדקות ומורידות עומס גם מהמערכות התפעוליות.
ורק עכשיו: החומרה
אחרי שהמודל רזה, הביטויים נקיים והטעינות מסודרות, אם עדיין צר, זה הזמן לדבר על זיכרון ומעבדים. ההבדל הוא שעכשיו תקנו שרת שמשרת ארכיטקטורה בריאה, במקום שרת שמסתיר ארכיטקטורה חולה. וזה גם הרגע לבדוק אם בכלל מדובר בבעיה של עומס משתמשים, שפתרונה תזמון ופיזור, לא ברזל.
צ'קליסט אבחון: שמונה בדיקות לפי הסדר
- מה בדיוק איטי: פתיחה, אינטראקציה או Reload?
- יש מפתחות סינתטיים או לולאות במודל?
- כמה שדות במודל באמת בשימוש? (יש כלים שבודקים)
- יש שדות בקרדינליות עצומה שאפשר לפצל או להסיר?
- יש IF מקוננים או AGGR כבדים במדדים המרכזיים?
- תנאים עסקיים קבועים מחושבים בסקריפט או בממשק?
- יש שכבות QVD וטעינה אינקרמנטלית?
- מתי בפעם האחרונה מישהו מדד, ולא ניחש, איפה הזמן הולך?
השורה התחתונה
ביצועים הם לא תכונה של שרת, הם תכונה של תכנון. אפליקציה מהירה היא כמעט תמיד אפליקציה שמישהו חשב עליה, ואפליקציה איטית היא הזמנה לחשוב מחדש, לא לשלם יותר.