שיפור ביצועים ב-Qlik Sense: ממה מתחילים?

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

הנה סדר האבחון שאנחנו עובדים לפיו, מהזול לַיקר.

קודם כול: להבין מה בדיוק איטי

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

תחנה 1: מודל הנתונים

זה החשוד המרכזי, וכמעט תמיד בצדק. הדברים שמכבידים ביותר:

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

תחנה 2: הביטויים בממשק

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

• שרשראות IF מקוננות בתוך מדדים, במקום דגלים שחושבו מראש בסקריפט. ההבדל בביצועים יכול להיות של סדרי גודל.
• Count Distinct על שדות ענקיים בכל רענון של כל אובייקט.
• AGGR מסובכים שבנו כדי לפתור בעיה שהייתה צריכה להיפתר במודל.

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

תחנה 3: תהליך הטעינה

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

כמה עולה לא לטפל בזה

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

הערה למי שכבר בענן

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

שלושה דפוסים שחוזרים כמעט בכל אבחון

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

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

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

למדוד, לא לנחש

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

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

ורק עכשיו: החומרה

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

מתי השרת בכל זאת אשם

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

צ'קליסט אבחון: שמונה בדיקות לפי הסדר

השורה התחתונה

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

רוצים להבין איפה הנתונים שלכם נתקעים? נשמח לשיחה קצרה.