הוראות הפעלה לשיפור הביצועים של המערכת שלכם
יובל לשם
21.09.2015
ואפילו בלי רטלין. יובל לשם רוצה שתישארו רגועים ותנתחו נתונים. הרי במה מותר ההייטקיסט על המוסכניק, אם לא בקובץ האקסל שלו?
זה קורה לכל מי שכותב תוכנה.
אני יודע, לכם זה בטח לא קרה אף פעם. הכל עבד יופי בבדיקות, בשרת המקומי, אבל ברגע שהמערכת עלתה ללייב ומשתמשים אמתיים התחילו להתחבר, הביצועים נהיו, איך לומר, לא משהו. כמעט כל מערכת שקופצת במספר המשתמשים מ-100 ל-10000 תגיע למצב כזה. אם יש לכם אפליקציה, זמני התגובה יזנקו. אם יש לכם אתר, הדפים יטענו לאט.חלק גדול מההצלחה של הרבה חברות ווב ואפליקציות תלוי לא רק ביכולת להגדיל את מספר המשתמשים (או הורדות) שלהן, אלא גם ביכולת שלהן לתת למשתמש חווית שימוש מעולה. וחלק גדול מחוויית שימוש טובה זה מהירות תגובה. ב-Google IO (ועידת מפתחים ה.מ.) בשנה שעברה אף ציינו, שכאשר משתמש מחכה מעל 10 שניות לתגובה באפליקציה, הוא נוטה לסגור אותה.
אז, כולם כועסים עלינו, מאוכזבים מהביצועים ולוחצים לפתור את הבעיות אתמול. המנכ״ל שולף סיפור מהתקופה שהוא היה מקודד, איש המכירות ממהר לדמו וחייב שתפתרו את הבעיה בחצי שעה הקרובה, ומצבם לא הרבה יותר טוב משלכם - הם מסתכלים עליכם כמו שלקוח אומלל עומד מול המוסכניק שלו, בעוד זה אומר לו ״נפתח נראה, לא יודע כמה זמן או כסף זה ייקח".
מה עושים? (ההוראות כתובות בלשון רבים זכר אך ורק מטעמי נוחות)
קודם כל - אל תכנסו לפאניקה! צעדים דרסטיים בדרך כלל רק יריעו את המצב. הישארו ממוקדים, כי הזמן בכל זאת עובד לרעתכם.
הפתרון האוטומטי הראשון בהרבה חברות יהיה שדרוג החומרה. אלא אם אתם ממש נואשים, לא הייתי ממליץ. פתרון כזה במקרה הטוב ידחה את הקץ ולא ״יחזיק מים״ לאורך זמן, ובמקרה הרע ייכשל, ואז מצבכם יורע בהרבה.
העצה הכי טובה שקבלתי בצעירות הייתה שהכל בקוד. אין תחליף להבנה של מה שבאמת קורה בקוד שלכם. ברגע שהעומס עולה, תמיד יצופו דברים שלא היינו מודעים אליהם.
* השתמשו במדידת זמנים בכל שכבה באפליקציה שלכם. כמה זמן כל שאילתה לוקחת, העברה של מידע, כניסה ויציאה מתור - מקצה לקצה.
* תתחילו לנתח את מה שייצא. ברגע שיהיו מספיק לוגים, תבחרו את עשרת הפעולות שלוקחות הכי הרבה זמן. מתוכן, תבחרו את הפעולות שאפשר לשפר הכי בקלות (2-3 כאלו).
* נתחו את השליפות מהDatabase-. בחרו את השאילתות הכי נפוצות שלכם - אלו לוקחות הכי הרבה זמן עיבוד מה-Database. יש מצב שהעברת טבלאות, קטנות יחסית, ל-cache תחסוך לכם הרבה זמן.
* אל תנתחו סתם. תוכיחו דברים. השתמשו בטבלאות excel כדי למדוד פעולות ולסכום. תעשו סטטיסטיקה אמתית. בחברה שייעצתי לה, היו מבצעים בכל דף ווב שאילתה על מנת להוריד את הלוגו של הלקוח, שאוחסן כבלוב ב-Database. השאילתה תפסה בעומס CPU שלם.
* בדקו זמני הכנסת נתונים - שימוש בתורים עשוי לפתור צווארי בקבוק די בקלות.
* אל תעבדו לבד - ארבע עיניים טובות משתיים. קחו חבר לעבור אתכם על הקוד, במיוחד אם אתם מכירים אותו ״טוב מדי״ בשביל למצוא בו טעויות.
* תקראו למומחה - לפעמים הרבה יותר זול לשלם למישהו על יומיים יקרים של עבודה מאשר לאבד שבועיים של מומנטום והרבה משתמשים.
* קחו הפסקות כדי לחשוב - לא תמיד הפתרונות מגיעים כשאתם מול המחשב. לבהות 15 שעות רצוף בקוד על מנת לפתור בעיה ספציפית בדרך כלל יגרור תופעות הפוכות כמו ״ניחושים״, הדפסות לוג בלתי מובנות, הודעות משתמש מוזרות ששוכחים להעיף וכדומה.
* היו שקופים עם כולם - סביבה רגועה יותר עוזרת לפתרון מהיר של הבעיה. שקיפות עוזרת להרגיע את המנהלים והשותפים שלכם. גם אם אין לכם בשורות טובות עדיין, הסבירו על התהליך. יכול להיות אפילו שתרוויחו עצה טובה.
והכי חשוב: פוקוס וחדות הן שתי התכונות החשובות בפתרון של בעיות ביצועים. אם תנסו ״לשכתב את השרת״ ביומיים נטולי שינה, אל תיקחו על עצמכם יותר משימות משתוכלו להתמודד עימן.
יובל לשם הוא סמנכ"ל פיתוח ב-lightapp.com
