ישנה כמות חומר אדירה ומיומנות מדהימה בנושא ארכיטקטורת ביצועים (Performance), ניתוח ביצועים, שיפור ביצועים, אפיון ביצועים, בישול ביצועים ומה לא. עמיתיי אליק לוין וטל בן שלום מובילים את הנושא ואני ממליץ מאוד על מאמרים, פוסטים ותוצרים שהם מספקים בנושא (ראה בסוף הפוסט הנוכחי לינקים מומלצים בנושא).
אך למרות הפעילות הענפה בנושא עדיין השאלה הראשונה שנשאלת כאשר המילה "ביצועים" נזרקת לחלל האוויר, היא: "למה הכוונה במונח 'ביצועים' ?". ולעתים קרובות מדי, התגובות לשאלה מהווים ניסיון להגדיר במונחים מאולתרים (במידה זו או אחרת) את כוונת הדובר, ולהפוך את המונח "ביצועים" לדרישה מדידה, אך ללא היכרות עם מגוון ההגדרות והמונחים הקיימים והנפוצים שכלולים תחת הקטגוריה הכללית של "ביצועים".
בפוסט הזה אני אנסה לתאר את מגוון האפשרויות והמונחים אליהם מתכוונים כאשר מדברים וחושבים על ביצועים (Performance). כמובן שאיני מתכוון להמציא את הגלגל מחדש, אלא להסתמך על הגדרות ותובנות מקובלות ונפוצות., ובראש ובראשונה על מרטין פאולר (Martin Fowler) שכלל התייחסות לנושא החשיבה על ביצועים בספרו (המצוין והמומלץ) "Patterns of Enterprise Application Architecture".
איני מתכוון לנסות ולתאר את ההגדרות האקדמיות של המונחים, אלא לתאר את הההגדרות הנפוצות בראייה מעשית של פיתוח אפליקציות ומערכות, והשימוש האפשרי והנפוץ במונחים אלו בעת פעילות איסוף הדרישות (בדר"כ דרישות לא-פונקציונאליות, או דרישות Quality Attributes) עיצוב הארכיטקטורה ואפיון הפתרון.
Response Time –
זמן תגובה הוא פרק הזמן שנדרש למערכת (לרכיב ממשק המשתמש או למנגנון לוגי נפקד ממשק המשתמש, כגון API function כלשהו) להגיב לבקשה שמתקבלת ממקור חיצוני. הכוונה אינה רק לפרק הזמן שנדרש לבצע את עיבוד הבקשה (זהו ה – Processing time), אלא גם לפרק הזמן שנדרש להפיק ולשלוח את התשובה (Response) עצמה.
ישנה מידה מסוימת של אי בהירות לגבי נקודת המבט ממנה יימדד ה - Response Time: האם מנקודת המבט של מבקש הבקשה או של מקבל הבקשה ? אני אישית נוטה לאמץ את הגישה ש – Response Time נמדד מנקודת המבט של המבקש (אחרי הכל, המונח המרכזי הוא "Response"), ובהתאם לכך, תיאור ויזואלי של ההגדרה ייראה כך:
Responsiveness -
אפשר לתרגם זאת כ"תגובתיות", אם כי זה נשמע לי כמו תרגום גמלוני למדי. זהו ניסיון לאמוד את מידת היכולת של המערכת לספק תגובה כלשהי לבקשה שמגיעה ממקור חיצוני, כאשר התגובה באה (רצוי) בפרק זמן מוקדם יותר מה – Response Time המלא.
לכאורה, Responsiveness הינו מאוד מדד דומה ל – Response Time, אך מטרתו היא לספק אינדיקציה לפעילות (או אינדיקציה להתקדמות בפעילות) אשר ה – Response Time שלה הוא ארוך מספיק על מנת להצדיק הקדשת משאבים מסוימת על מנת להציג תגובה מוקדמת, לפני השלמת הפעולה (כלומר, לפני ה – Response Time).
למרות שהקונטקסט הנפוץ של Responsiveness הוא ממשק משתמש, יש מגוון תסריטים שבהם מבקש הבקשה אינו אנושי, אלא ממשק ממוכן כלשהו אשר דורש "אישור קבלה" או "דיווח התקדמות" (בעיקר בתסריטים שכוללים Long Running Processes).
הניסיון לספק responsiveness יכול לבוא לידי ביטוי במגוון דרכים. רשימה חלקית ולא ממצה תכלול:
- מתן תגובה על קבלת הבקשה (receipt)
- אספקת אינדיקציה להתקדמות (כגון מידע אשר יכול לשמש ליצירת Progress bar בממשק המשתמש) בדמות עדכון תקופתי על שינוי סטטוס בעיבוד הבקשה
- אספקת מידע חלקי ו\או אינקרמנטלי אשר למרות היותו מענה חלקי לבקשה.
כתוצאה, תינתן תגובה ראשונית בפרק זמן קצר מפרק הזמן המוגדר ע"י ה – Response time, וע"י כך ישפר את ה – Responsiveness. מונחים כגון TTFB ו – TTLB יכולים לשמש כאומדן לאספקת מידע חלקי. אפשרות אחרת היא לספק פתרון chunking של המידע (חלוקת המידע שבתגובה לחלקים, כגון pages של מידע הנפוצים בתצוגת מידע טקסטואלי, או streaming של מידע, בדר"כ בינארי כגון וידאו או אודיו).
הערה: ייתכן ובתסריטים מסוימים, ה – Response Time עצמו יוגדר כפרק הזמן עד לקבלת החלק הראשון מהמידע החלקי. לדעתי זוהי הגדרה תקינה לחלוטין, היות וכאמור, Response Time מוגדר ע"י מבקש הבקשה (או בפראפרזה על "הלקוח תמיד צודק" – הלקוח מגדיר מהו ה – Response Time)
הדוגמא הקלאסית לטכנולוגיה מוכוונת Responsiveness היא AJAX. בסופו של דבר, מטרת השימוש ב –AJAX היא שיפור ה – Responsiveness של הדפדפן. שיטת היישום של AJAX מחקה את שיטת היישום של שיפור ה – Responsiveness של טכנולוגיות Smart client כגון WinForms או WPF, והיא מתבססת על יצירת background thread אשר מנהל את פעילות משלוח הבקשה ועיבוד התגובה מאחורי הקלעים, בלא לחסום את ממשק המשתמש (דהיינו, בתסריט של הדפדפן, בלא להטריד את משתמש הדפדפן במסך הלבן המציין המתנה לתשובה משרת האינטרנט).
במובן זה, Responsivess הינו במידה רבה אחיזת עיניים: שימוש בטריקים ויזואליים על מנת לספק תחושה סובייקטיווית של Response Time מהיר יותר (לדוגמא: הצגת שעון חול, או Progress bar, או פרסומת וכו'). בפועל, לעתים קרובות אספקת Responsiveness מהיר יותר דורשת פעילויות עיבוד ותצוגה נוספות, ולפיכך יכולה לפגוע במידה מסוימת ב – Response time המדיד מבחינה אובייקטיווית (בדר"כ מדובר על פגיעה שולית).
כתוצאה, ניתן לראות בשיקול האם לעשות שימוש ב – Responsiveness כסוג של חישוב ROI: האם ההשקעה בשיפור ה – Responsiveness, והפוטנציאל לפגיעה מסוימת ב – Response Time, תוביל לתחושה סובייקטיווית של המשתמש כי ה – Response Time השתפר, במידה אשר מצדיקה את המאמץ והמורכבות הנוספים הכרוכים באספקת פתרון Responsiveness ?
Latency –
פרק הזמן המינימלי הנדרש לקבלת תגובה, בין אם זו תגובה ראשונית (כגון אישור קבלת בקשה), תגובה חלקית ("הנה ה – chunk הראשון של המידע שביקשת") או תגובה מלאה.
בהפשטה, אפשר לתאר את ה – Latency כשילוב של אילוצים הנגזרים מחוקי הפיזיקה: סה"כ זמן העיבוד, וסה"כ זמן התעבורה ברשת (במערכת מבוזרת) וכן התעבורה בין רכיבי המחשב השונים. בראייה מפורטת יותר התמונה קצת יותר מורכבת היות וישנם מגוון של רכיבי ביניים (לדוגמא, במערכת מבוזרת ישנם נתבי תקשורת, רכיבי חומרה\תוכנה כגון Proxies, firewall וכדומה) ובתקשורת מקומית ישנם היבטים נוספים מעבר להעברת המידע ל – CPU או הצגתו למשתמש (כגון סנכרון cache בין מעבדים שונים בסביבה מרובת מעבדים וכדומה).
התמונה המנטאלית שאני מנסה ליצור כאשר אני חושב על Latency, היא של הנתיב ופרק הזמן הקצר ביותר האפשרי לקבלת תגובה כלשהי (בין אם בהיבטי Response time או Responsiveness), מנקודת המבט של מבקש הבקשה, כאשר אופי התגובה הרצויה מוכתב בעיקר ע"י התסריט העסקי (כלומר, ע"י דרישות פונקציונאליות).
Throughput -
כמות הפעילות שניתן לבצע בפרק זמן נתון. ההגדרה של "פעילות" בהקשר זה נתונה לחלוטין לדיון בהקשר של התסריט הספציפי. פעילות יכולה להימדד במספר Bytes שיעובדו בשנייה, או כמות הטרנאזקציות שיבוצע להן Commit, או כמות הבקשות שיטופלו.
בדרך כלל (אך לא תמיד), ה - throughput מהווה הכפלה של מדד כלשהו מבין המדדים הקודמים (Response Time, Responsiveness או Latency) במידה מסוימת של מקביליות (parallelism) אשר נובע מיכולות חומרה או תוכנה או מנגנוני תקשורת (או שלושתם) לבצע פעילות מקבילית.
לפיכך, כאשר אני מנסה לנסח את דרישות או פוטנציאל ה – throughput, אני מתחיל באיתור המדד הבסיסי והפעילות לפיה הוא ימדד, ולאחר מכן בוחן את אפשרויות ההכפלה באמצעות parallelism. לדוגמא: אני מתחיל בבחירת מדד כגון ה - Response Time של פעילות כגון Transactions / sec. לאחר מכן, אני בוחן את אפשרויות ה - parallelism: האם יש לי אפשרות להשתמש רק ב – CPU אחד (ואז אין לי אפשרויות מקביליות בחומרה, אך ייתכן ויש לי אפשרות למקבל את הפעילות באמצעות תוכנה, כגון ע"י שימוש ב – Multi-tasking של מערכת ההפעלה), או שיש לי אפשרות להשתמש במספר רב של מעבדים, ואולי אפילו יש לי אפשרות לפצל את פעילות העיבוד בין מחשבים שונים תוך שימוש בתשתית תקשורת מתאימה (כאן אפשר להמשיך לדיון על Scale-out – ראה בהמשך בנושא Scalability).
Performance –
בדר"כ אפשר להגדיר את המונח "ביצועים" (Performance) על בסיס המונחים שהוגדרו עד כה. בתסריט מסוים יוגדר Performance כ – "Response time נמוך משנייה ב – 90% מהמקרים", ובתסריט אחר יוגדר Performance כ – "Throughput גבוה מ – 100 טרנזאקציות בשנייה".
הבחירה בין אפשרויות ההגדרה השונות של המונח Performance תתבצע לרוב על בסיס שיקולי דרישות פונקציונאליות או דרישות לא-פונקציונאליות (Quality Attributes). עם זאת אפשר גם לקבוע כי הגדרת המונח Performance בהקשר מסוים תתבצע על בסיס או תוך שילוב מגוון המונחים הבאים (כגון load, efficiency או scalability מסוג מסוים). עם זאת, הנטייה בנושא היא לבסס את המונח הגולמי של Performance על הגדרות בסיסיות של Response Time ו\או throughput ו\או latency, ולאוו דווקא לכלול בהגדרה את המונחים הרחבים יותר של load ו – scalability. אלו בדר"כ ראויים להגדרה נוספת, רחבה יותר, של היבטי התנהגות המערכת.
Load –
ה – Load ("עומס") הוא מדד אשר מהווה תיאור של המערכת במונחי מדד פעילות. לדוגמא: ה – Load של מערכת יכול להיות מתואר כ – "20 בקשות בשנייה", או "100 משתמשים פעילים".
רצוי וכדאי להשוות את ה – Load ל – Throughput, הן בשלב הגדרת המדדים עבור התסריט הספציפי, והן בהיבטי מדידה בפועל. בשלב ההגדרה רצוי לספק לשני המונחים הנ"ל הגדרות משלימות ותואמות (לדוגמא: אם throughput יימדד במונחי טרנזאקציות לשנייה, רצוי גם שמדד ה –Load, או אחד ממדדי ה – Load, יכללו התייחסות לכמות הטרנזאקציות בשנייה). הסיבה לכך היא שפער בין יכולות ה – throughput לבין מדד Load התואם לו, יכול לספק אינדיקציה לפערים בארכיטקטורת ועיצוב המערכת (לדוגמא: אם ה – throughput האפשרי הוא 100 טרנזאקציות בשנייה, אך ה – Load הוא 110 טרנזאקציות בשנייה, ישנו פער שלילי בין יכולת המערכת לדרישות ממנה, ויש להגדיל את יכולת ה – throughput של המערכת או להתמודד עם תור הולך וגדל של בקשות שלא ייענו, או ייענו בהודעות שגיאה ו –timeout. להבדיל, מצב שבו ה – throughput האפשרי הוא 100 טרנזאקציות בשנייה, אך ה – Load הוא 10 טרנזאקציות בשנייה מעיד על עודף משמעותי במשאבי מערכת שלא מנוצלים).
Load Sensitivity –
זהו מדד המורכב משילוב של Load ומדד נוסף כגון Response Time, ומתאר את השינוי היחסי במדד אחד בעקבות שינוי של מדד אחר. לדוגמא: "Response Time של עד שנייה אחת כאשר יש עד 100 טרנזאקציות בשנייה, ו – Response Time של שנייה אחת עד שתי שניות כאשר יש יותר מ – 100 טרנאזאקציות בשנייה".
ניתן להציג את Load Sensitivity כגרף המשלב שני צירים. לדוגמא:
הגרף מתאר את ה – Load העולה (במונחי Transactions/second) ואת ה – Response Time המשתנה בהתאם ל – Load המשתנה. ניתן לראות בגרף את פריט המידע השימושי ביותר הנובע מ – Load Sensitivity, והוא ה"ברך" בביצועים: הנקודה שבה ה – Load משפיע על מדד הביצועים (במקרה זה, ה – Response time) במידה שמכופפת את גרף ה – Response time ביחס ל – load (כיפוף הגרף הוא הבסיס לכינוי "ברך". בגרף המצורף ניתן לראות כי ה"ברך" מתרחשת כאשר ה - Load מגיע ל ~220 טרנזאקציות בשנייה).
Efficiency –
יעילות בהקשר של ביצועים יכולה להיות מבוטאת בהתבסס על מדד יחסי ו\או מדד כספי.
מדד יחסי מציין את ה- Load Efficiency ביחס למדד רצוי או מערכת אחרת. לדוגמא, מערכת אשר מספקת Response time של 5 שניות תחת עומס של 220 טרנזאקציות בשנייה, הינה מערכת פחות יעילה מכזו שמספקת Response Time של 2 שניות תחת עומס דומה.
מדד כספי יכול לציין את העלות הכספית של המערכת בחלוקה למדד Performance נתון. לדוגמא, "מערכת שעלותה 10,000$ ויכולה לעמוד ב – throughput של100 טרנזאקציות בשנייה ו – Response Time של פחות משתי שניות". אם המדד המרכזי של המערכת הוא כמות הטרנקזאקציות בשנייה, אז ניתן לומר שעלות כל טרנאקציה לשנייה הוא 100$ (תוצאת חישוב 10,000 חלקי 100 טרנקאזציות לשנייה). בדרך כלל, כאשר מגיעים לדיון מסוג זה, השלב הבא הוא ניסיון זוחל של הלקוח ליצור גרף המתאר את יעילות העלות לאורך טווח מדד הביצועים (לדוגמא, ע"י שאלות כגון "כמה תעלה לי מערכת שמסוגלת לספק 200 טרנאקציות בשנייה ב – Response Time של פחות משתי שניות ?"). בדרך כלל קשה מאוד לספק תשובות לשאלות כאלו ללא בדיקה אמפירית (שעלותה משתנה אך לרוב משמעותית).
Capacity –
אינדיקציה של מדד מקסימלי של מערכת באמצעות שימוש במונחים כגון Throughput או Load (לדוגמא: "100 טרנאקציות בשנייה", או "150 משתמשים פעילים").
ה"מקסימליות" של המדד אינה מוחלטת, אלא בדרך כלל נקבעת ע"פ מיקום שבו המדד הופך להיות לא יעיל.
דוגמא למיקום לא יעיל שכזה הוא ה"ברך" שאותרה במסגרת מדידת Load Sensitivity (ראה דוגמא לעיל). בדוגמא הזו אפשר לומר שה – Capacity של המערכת הוא 220 טרנזאקציות בשנייה, היות וכל גידול ב – Load (בכמות הטרנזאקציות בשנייה) יביא לגידול לא פרופורציונלי (ולא מקובל מבחינה עסקית) של ה – Response Time.
דוגמא נוספת למיקום של של הגדרת Capacity היא בהיבט של עלות\תועלת (ראה הגדרת המונח Efficiency), כגון במצב שבו תוספת משאבים מביאה לשיפור שולי במדד על פיו נמדד ה – Capacity. וכמעט בכל דיון העוסק בנושא זה, מגיעים בשלב הזה לדיון בהיבטי Scalability של המערכת.
Scalability -
Scalability היא מדד של היחס בין הוספת משאבים (בדר"כ חומרה) לבין שיפור במדד ה – Performance הרלוונטי. ככל שהיחס הוא יותר חיובי (הוספת משאבים מגדילה את מדד ה – Performance באופן חיובי, בעיקר תוך הכללת שיקולי Efficiency ועלות\תועלת).
האפשרויות של Scalability היו בעבר פשוטות וקלות: Scale-out לעומת Scale-up, כאשר אפשרות ה – Scale-up היוותה אמצעי מילוט מבטיח לאנשי פיתוח עצלים ("המערכת לא מספקת את הביצועים הנדרשים? בואו נרכוש חומרה חזקה יותר!"). הקפאון בגידול במהירות מעבדים, הפך את האופציה הזו ללא רלוונטית (ראה המאמר המצויין The Free lunch is over של Herb Sutter).
שתי האפשרויות שנותרו לפיכך, הן Scale-out כשימוש במספר רב של שרתים, או Scale-out כשימוש במספר רב של CPU או CPU-Cores (אפשרות זו נחשבת בעיניי ב – Scale-out היות והיא דורשת את אותם המאפיינים הבסיסיים של Scale-out למספר רב של שרתים: אפשרות לבצע partitioning של הפעילות הנדרשת, והאפשרות לבצע הפרדה של state מפעילות העיבוד עצמה).
מבין כל אפשרויות האופטימיזציה הזמינות לשיפור יכולות המדדים השונים שתוארו בפוסט זה, אני חושב שאין ספק שהמדד הקל ביותר לשיפור (לפחות בהיבטי עלות\תועלת) הוא מדד ה – Scalability. מתוך הנחה שיש בידינו מערכת שמספקת יכולת scalability טובות (בהיבטי scale-out שנדונו לעיל, והיות ויש מידע וניסיון רב כיצד לבנות מערכות כאלו, אני מאמין שזו דרישה מציאותית מאוד בימינו) אז לרוב הרבה יותר זול ומהיר "לזרוק חומרה על הבעייה" על מנת לספק פתרון לדרישות ביצועים. ההיבטים הכלכליים והמודל העסקי של Cloud Computing הופך מגמה זו לכדאית ויעילה הרבה יותר מבעבר, ולהערכתי מגמה זו רק תתחזק עם התגברות התחרות בין ספקי יכולות Cloud Computing (בדגש על ספקי IaaS ו - PaaS), וכן עם הוספת עוד ועוד CPU Cores לשרת הממוצע.
תכנים נוספים בתחומי ביצועים:
Improving .NET Application Performance and Scalability
http://msdn.microsoft.com/en-us/library/ms998530.aspx
Performance Testing Guidance for Web Applications http://www.codeplex.com/PerfTestingGuide
אליק לוין על Performance
http://blogs.microsoft.co.il/blogs/alikl/archive/tags/Performance/default.aspx
שירותי MCS בתחום:
| |
שמי דני כהן ואני ארכיטקט ויועץ בצוות MCS Israel, ומתמחה במערכות מבוזרות, Cloud Computing, מתודולוגיות פיתוח וארכיטקטורת תוכנה. |