בהמשך לשאלה שנשאלתי אודות ההבדל בין ה- compressions השונים שאפשר לעשות לתמונות ואשר ניתנים להגדרה בפרוקוטול ה- HDX\ICA, החלטתי לבדוק את העניין לעומק.
ערכתי בסך הכל 12 בדיקות, כשכל אחת עם הגדרה מעט שונה. כל הבדיקות נערכו על תמונות דוממות מהאתר
הזה. ביטלתי את אפשרות ה- Off Screen Surface כדי שה- agent המקומי שלי לא יקח את התמונות מה- Cache, אלה יביא אותם כל פעם מהסביבה המרוחקת.
הבדיקה כללה פתיחה של IE על אתר הדגימה (כל האתר נטען מבעוד מועד בכל אחת מהבדיקות) וגלילה – עם page down בקצב איטי יחסית – עד סוף הדף.
ועוד דבר קטן, כל הבדיקות בוצעו ע”י התחברות לסביבה עם Latecny גבוה יחסית של 200ms וקו של 1.5M.
מי שמעוניין להגיע ישר לסיכום התוצאות, מוזמן לגלול לסוף הדף.
בדיקה 1: Still Images Lossy Compression - High
התמונות עלו בצורה מהירה, ראו ירידה מסוימת באיכות התמונות.
תקשורת – ממוצע של 109Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית, עם פיק של 201Kbits/sec.
עבודה מול הדיסק – ממוצע של 1.3IOPS (כולם כתיבה)
השפעה על מעבד ו- RAM – ממוצע של 40% שימוש במעבד ו- 1.2GB של RAM פנוי (מתוך 2GB).
בדיקה 2: Still Images Lossy Compression – Medium
התמונות עלו בצורה מהירה, באיכות יותר טובה יחסית ל- High Compression, אבל עדיין, באיכות פחות טובה מהמקור.
תקשורת – ממוצע של 217Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 4Kbits/sec של תקשורת נכנסת. פיק של 414Kbits/sec של תקשורת יוצאת ו- 5Kbits/sec של נכנסת.
עבודה מול הדיסק – ממוצע של 5IOPS (כ- 4 כתיבה וכ- 1 קריאה) במשך הבדיקה.
השפעה על מעבד ו- RAM – ממוצע של 36% שימוש במעבד ו- 1.2GB של RAM פנוי.
בדיקה 3: Still Images Lossy Compression – Low
התמונות עלו בצורה איטית יותר מאשר בשתי הבדיקות הקודמות, אך איכותן היתה טובה מאוד ועדיפה מאשר בבדיקות הקודמות.
תקשורת – ממוצע של 307Kbits/sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 3Kbits/sec של תקשורת נכנסת. פיק של 530Kbits/sec של תקשורת יוצאת ו- 4Kbits/sec של נכנסת.
עבודה מול הדיסק – ממוצע של 2IOPS (כולם כתיבה) במשך הבדיקה. העליה בסוף, היא בגלל סגירת חלון הדפדפן.
השפעה על מעבד ו- RAM – ממוצע של 34% שימוש במעבד ו- 1.2GB של RAM פנוי. העליה בסוף, היא בגלל סגירת חלון הדפדפן.
בדיקה 4: Still Images Lossy Compression – None
התמונות עלו בצורה איטית ומייגעת מאוד, מה שכן, האיכות שלהן – אחרי שהן כבר הופיעו – היתה מצוינת.
תקשורת – ממוצע של 500Kbits\sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית ו- 3Kbits\sec של תקשורת נכנסת. פיק של 863Kbits\sec של תקשורת יוצאת – 4Kbits\sec של תקשורת נכנסת.
עבודה מול הדיסק – ממוצע של 1.5IOPS (כולם כתיבה) במשך הבדיקה.
השפעה על מעבד ו- RAM – ממוצע של 33% שימוש ובמעבד ו- 1.2GB של RAM פנוי.
בדיקה 5: Still Images Lossy Compression – High; Heavyweight Compression – Enabled
התמונות עלו בצורה מהירה, ראו ירידה מסוימת באיכות התמונות.
תקשורת – ממוצע של 160Kbits\sec של תקשורת יוצאת מהסביבה הוירטואלית לעמדה הפיזית וממוצע של 2.5Kbits\sec של תעבורה נכנסת. פיקים של 280Kbits\sec ו- 3.9Kbits\sec של תעבורה יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 3IOPS (כולם כתיבה) לאורך הבדיקה.
שימוש במעבד ו- RAM – ממוצע של 35% שימוש במעבד, כמעט ללא השפעה על ה- RAM.
בדיקה 6: Still Images Lossy Compression – Medium; Heavyweight Compression – Enabled
תקשורת – ממוצע של 208Kbits\sec של תקשורת יוצאת ו- 3Kbits\sec של נכנסת. פיקים של 286Kbits\sec ו- 3Kbits\sec של יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 2IOPS (כמעט כולן כתיבה).
שימוש במעבד ו- RAM – ממוצע של 37% שימוש במעבד, השפעה מועטה על ה- RAM.
בדיקה 7: Still Images Lossy Compression – Low; Heavyweight Compression – Enabled
תקשורת – ממוצע של 328Kbits\sec תעבורה יוצאת ו- 3Kbits\sec של נכנסת. פיק של 502Kbits\sec ו- 4Kbits\sec של תעבורה יוצאת ונכנסת.
עבודה מול הדיסק – ממוצע של 1.7IOPS (כולם כתיבה).
השפעה על מעבד ו- RAM – ממוצע של 33% שימוש במעבד.
בדיקה 8: Still Images Lossy Compression – None; Heavyweight Compression – Enabled
קצב העברת התמונות היה איטי להחריד…
תקשורת – ממוצע של 577Kbits\sec תעבורה יוצאת ו- 3Kbits\sec נכנסת. פיק של 932Kbits\sec ו- 4.4Kbits\sec של יוצאת ונכנסת בהתאמה.
עבודה מול הדיסק – ממוצע של 1.5IOPS (כולם כתיבה).
השפעה על המעבד ו- RAM – ממוצע של 34% שימוש במעבד.
בדיקה 9: Still Images Lossy Compression – High; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
תקשורת – ממוצע של 188Kbits\sec יוצאת ו- 3Kbits\sec נכנסת. פיק של 310Kbits\sec ו- 4Kbits\sec תעבור יוצאת ונכנסת בהתאמה.
עבודה מול הדיסק – 3.6IOPS בממוצע (כולם כתיבה).
השפעה על מעבד ו- RAM -
בדיקה 10: Still Images Lossy Compression – Medium; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות היתה מעט איטית.
תקשורת – ממוצע של 177Kbits\sec של תקשורת יוצאת ו- 2.5 נכנסת. פיק של 305Kbits\sec של תעבורה יוצאת.
עבודה מול הדיסק -
השפעה על המעבד וה- RAM -
בדיקה 11: Still Images Lossy Compression – Low; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות היתה איטית.
תקשורת – ממוצע של 336Kbits\sec תעבורה יוצאת עם פיק של 532Kbits\sec.
עבודה מול הדיסק -
השפעה על המעבד ו- RAM -
בדיקה 12: Still Images Lossy Compression – None; Heavyweight Compression - Enabled; Extra Color Compression – Enbaled
מהירות העברת התמונות איטית מאוד.
תקשורת – ממוצע של 608Kbits\sec תעבורה יוצאת עם פיק 979Kbits\sec.
עבודה מול הדיסק -
השפעה על המעבד ו- RAM -
לסיכומו של עניין, טבלה קצרה שמרכזת את נתוני התקשורת היוצאת הממוצעת (כפי שאפשר לראות בתוצאות, זה הנתון שהכי הושפע מהשינויים בהגדרת ה- compression) בכל אחת מהבדיקות.
| None | Low | Medium | High | |
| 500 | 307 | 217 | 109 | |
| 577 | 328 | 208 | 160 | Heavyweight Compression |
| 608 | 336 | 177 | 188 | Extra Color Compression |
מסקנות. באופן מעט מפתיע, Heavyweight Compression למרות שהיה אמור לצרוך פחות רוחב פס, דווקא צרך יותר (פרט לכאשר ה- Lossy Compression היה מוגדר ל- Medium). כנ”ל גם בקשר ל- Extra Color Compression, גם כאן בכל הבדיקות פרט לכאשר ה- Lossy Compression הוגדר ל- Medium, צריכת רוחב הפס דווקא גדלה.
עוד נתון שלא ממש הפתיע אותי, אלה רק הראה את זה בצורה מאוד ברורה, הוא נתון העבודה מול הדיסק.
כמעט בכל אחת מהבדיקות, לא היתה שום קריאה מהדיסק בזמן השהייה בדף האינטרנט, גם הכתיבות אליו היו מועטות (ולא הושפע כלל מהגדרות ה- compression). אם מקשרים את הנתונים האלה לנתוני העבודה מול הדיסק שפירסמתי בבדיקות הקודמות, אפשר לראות באופן מאוד ברור כי רוב העבודה של תחנת ה- VDI מול האחסון (אחרי שהיא עלתה והמשתמש נכנס כבר לסביבה, שם הנתונים פחות או יותר הפוכים) היא דווקא בכתיבה.
בהמשך לפגישה מעניינת שהיתה לי היום עם ארגון מאוד מבוזר (סביבות ה- 200 סניפים ברחבי העולם) שחושב על אספקת סביבת עבודה וירטואלית מבוססת Windows 7 בתצורת VDI, חשבתי לבדוק כמה רוחב פס נדרש עבור סריקה של מסמך מתחנת VDI. כלומר, הסורק מחובר ב- USB לתחנה הפיזית ממנה מבוצע החיבור לסביבה הוירטואלית וממופה לסביבה הוירטואלית.
כמו שכבר
התלוננתי, ה- Latency שלי לסביבה הוירטואלית הוא בסביבות ה- 200ms, בדומה ל- Latency בין ישראל לחוף המזרחי של ארה”ב, ככה שהבדקתי דימתה – פחות או יותר – חיבור של משתמש בחוף המזרחי של ארה”ב לסביבה וירטואלית אשר רצה בישראל. לפחות משהו טוב יצא מכל העניין הזה.
סרקתי ארבעה מסמכים, כולם כתובים בשחור לבן, בגודל דף של A4 (אף אחד מהם לא היה מלא לחלוטין).
שני המסמכים הראשונים נסרקו עם ההגדרות: JPEG, 200 DPI, color.
הסריקה ראשונה התחילה ב- 17:42 והסתיימה ב- 17:44.
הסריקה השניה התחילה ב- 17:45 והסתיימה ב- 17:48.
שני המסמכים האחרונים נסרקו עם ההגדרות: JPEG, 200 DPI, black & white.
הסריקה השלישית התחילה ב- 17:50 והסתיימה ב- 17:52.
הסריקה הרביעית התחילה ב- 17:54 והסתיימה ב- 17:55.
כמו שאפשר לראות, הסריקות לקחו יחסית יותר זמן מאשר במחשב מקומי, אבל אני תולה את האשם ב- Latency “המכובד”, בעיקר בגלל שבפעם האחרונה שסרקתי באותה הצורה (בימים בהם ההתחברות לסביבה המרוחקת עבדה הרבה יותר טוב), סריקת מסמכים זהים יחסית לקחו פחות זמן מעכשיו.
בכל אופן, איכות הסריקה לא נפגעה.
תעבורה נכנסת (Input Kbits, מהתחנה הפיזית לסביבה הוירטואלית) ותעבורה יוצאת (Output Kbits, מהסביבה הוירטואלית לתחנה הפיזית). ממוצע (של 18 הדקות בהן ביצעתי סריקות) תעבורה נכנסת 30Kbits/sec, ממוצע תעבורה יוצאת 36Kbits/sec.
עבודה מול הדיסק, ממוצע של 0.5 קריאות לשניה וממוצע של 3.2 כתיבות לשניה. ממוצע סה”כ IOPS של 3.7 כתיבות וקריאות.
שימוש במעבד (ציר שמאל) וזיכרון RAM פנוי (ציר ימין)
אפשר לראות כי מה שהכי הושפע מהסריקה זאת תעבורת הרשת בין התחנה הפיזית לסביבה הוירטואלית, עם עליה לפיקים של סביבת ה- 140Kbit\sec של תעבורה נכנסת, גבוה יחסית למספרים שרואים ללא סריקה. קיימת גם השפעה קטנה יחסית על ה- IOPS (הגיוני מאוד, כי הסריקה נכתבת לדיסק) ועל המעבד והזיכרון שלוקחים חלק במאמץ.
כמעט חודש שלא עדכנתי על ההתפחויות בניסוי, ושלל סיבות יש לעניין. האחת הוסיפה עוד נדבך קטן ומעניין לניסוי והשניה הולכת לשנות – לפחות לעכשיו – את התצורה עליה אני עובד.
אז כאמור, הסיבה הראשונה היתה נסיעה ארוכה לחוף המזרחי של ארה”ב, מה שעזר לי לבדוק את ההתחברות לסביבה שלי גם מיבשת אחרת עם latency של סביבות ה- 200ms. עבד טוב בצורה מפתיעה וזה עוד לפני שעשיתי איזשהי אופטימיזציה בצד ה- XenDesktop. אחת הבדיקות היתה שיחת אודיו עם Lync (קליינט על תחנת ה- VDI ושיחה לטלפון קווי בישראל) שעברה בצורה מפתיעה לטובה. למרות ה- Latency הגבוה יחסית, ה- HDX ידע להשתמש בדרייבר האודיו והמיקרופון המקומי של המחשב, והשיחה נשמעה (בשני הצדדים) בצורה טובה מאוד.
הסיבה השניה היא בעיית Latency חמורה בהתחברות לסביבה שלי ב- HP שהתחילה לקרות, כך נראה לפחות, לפני כשבועיים. בהתחברות מהבית – או כל wifi אחר – אני מגיע לסביבות 180ms, בהתחברות דרך המודם הסלולרי המספרים מטפסים לכיוון ה- 300ms. הסביבה שלי נמצאת גם היא בישראל, ככה שהמספרים האלה מטורפים ולא הגיוניים בעליל. ד”א, לפני זה, ה- Latency עמד על 40ms מהבית מ- 100ms מהמודם הסלולרי.
כל עוד טובי המוחות בהודו - או בסרי לנקה, או בעצם בכל מקום אקזוטי אחר אליו עשו outsourcing - עובדים על העניין, החלטתי לעשות שינוי בסביבה עליה אני אעבוד וממנה יילקחו הנתונים.
הסביבה החדשה היא XenDesktop 5 FP1 (כמו הקודמת), וגם היא עובדת בתצורת MCS. השוני המרכזי שלה הוא בזה שבצד ה- hypervisor נמצא VMware vSphere 4.1 והסטורג’ כבר לא מקומי, אלה הוא דווקא vmax מרכזי. עוד שינוי חשוב הוא שההתחברות לסביבה היא על גבי LAN.
כל השאר זהה לתצורה הקודמת, התחנה הוירטואלית היא Windows 7 SP1, עם vCPU אחד ו- 2GB של RAM. היא עובדת בתצורת Dedicated (לא נמחקת בכל אתחול) והקליינט בתחנה ממנה מבוצע החיבור הוא Citrix Receiver 3.
רק כמה מילים לפני המספרים עצמם. הסביבה עליה אני עובד מאוד עמוסה (בגללי) עם שלל אפליקציות פתוחות ומספר טאבים פתוחים של IE (בד”כ סביבות 8), אפשר לראות את זה טוב בכמות ה- RAM הפנוי שנשאר לי. (ככה נראה ה- taskbar שלי במהלך רוב היום)
נתוני הרשת חסרים – למרות שבגלל שמדובר בסביבת LAN הם לא ממש רלוונטיים, אבל עדיין… – כי לקחתי בטעות counter לא נכון. העניין סודר, ככה שפוסטים הבאים יכילו גם נתוני תקשורת.
אחרי כל ההקדמה הארוכה הזאת, הנה נתוני צריכת המשאבים שלי.
אחסון:
קריאה, Read IOPS עם ממוצע של 3.54 קריאות לשניה.
כתיבה, Write IOPS עם ממוצע של 4.34 כתיבות לשניה.
סה"כ IOPS (ממוצע של 7.88 קריאות וכתיבות לשניה).![clip_image002[7]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image0027_thumb_15369888.png "clip_image002[7]")
התפלגות צריכת Read IOPS ו- Write IOPS באחוזים (בממוצע 17.7% עבור Read IOPS ו- 82.3% עבור Write IOPS).![clip_image002[9]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image0029_thumb_689D42D4.png "clip_image002[9]")
שימוש במעבד, vCPU אחד, ממוצע של 8.76%.![clip_image002[11]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image00211_thumb_68C9A03C.png "clip_image002[11]")
זיכרון RAM פנוי מ- 2GB שמוקצים למכונה הוירטואלית.![clip_image002[15]](http://blogs.microsoft.co.il/blogs/gadifeldman/clip_image00215_thumb_2ECA3783.png "clip_image002[15]")