מבוא:
במאמרים הקודמים דיברתי בעיקר על כלים מעניינים, על בעיות טיפוסיות, וקצת על פרוטוקולים. במאמר זה אני רוצה לדבר קצת על בדיקת ביצועים של יישומים, בדרך רגילה וגם עם כלי נחמד בשם Transum שפותח על ידי חברה בשם Tribelab ושולב כ- Plugin בתוכנת Wireshark.
קצת על עבוד של יישומים ברשת
כמו שידוע לנו, רוב היישומים עובדים מעל TCP, וזה אומר שקודם כל, בפתיחת יישום נראה את פתיחת ה- Connection ב- TCP. חשוב גם לזכור שיישום יכול להכיל מספר קישורים, ואפילו מספר רב. אם למשל נפתח עמוד אינטרנט, נראה מספר TCP Connections ואפילו מספר עשרות קישורים ויותר.
בואו ניקח לדוגמא עבודה ב- DB Client מול DB Server. בדוגמא DB-TNS Issue (קובץ מצורף) אנחנו רואים פתיחת TCP Connection ב- Packets 1-3, ומיד אחרי זה פקודת TNS Connect.
כשאנחנו פותחים יישום מסוים, היישום יכול לעבוד מול השרת ישירות כמו שרואים בתמונה הבאה.
כאשר בבדיקה של יישום מסוג זה נבדוק עם Wireshark המותקן בין השרת לתחנה, למשל עם Port mirror למבוא במתג עליו מחובר השרת, או נתקין Wireshark ישירות על השרת, ואם צריך גם על אחת התחנות שעובדת מולו.
אופן העבודה:
כמו שאנחנו רואים בתמונה, זמן התגובה של היישום (APDU Response Time) מורכב משלושה חלקים:
- זמן הבקשה (Application Request): כאן מדובר בזמן שלקח לבקשה של ה- Client להגיע ל- Server. ב- HTTP למשל אלו יהיו פקודות GET, POST וכד' עוברו ב- Packet שעוברות ב- Packet יחיד. ביישומים יותר מורכבים, בסיסי נתונים למשל, זו יכולה להיות בקשה במספר Packets, שתימשך גם יותר זמן.
- זמן עיבוד הבקשה על ידי השרת (Service Time): הזמן שלוקח לשרת/לתוכנה לטפל בבקשה, למשל למצוא את עמוד ה- HTTP המבוקש, לענות לשאילתה המבוקשת וכד'.
- זמן התגובה (Application Response): שהוא הזמן שלוקח לתשובה להגיע חזרה ל- Client. גם כאן יכולה להיות תגובה מהירה ב- Packet יחיד וגם תגובה במספר רב של Packets.
מקרה נוסף יכול להיות גם כאשר ה- Client מדבר עם שרת ביניים, למשל שרת HTTP, כאשר על שרת זה מותקן ה- Client שפונה לשרת הראשי, כמו בתמונה הבאה.
במקרה זה, כאשר אנחנו רוצים לבדוק גם את זמן הפניה מה- Browser ל- Web Server וגם מה- Web Server ל- Database Server או ל- File Server, הצורה הפשוטה ביותר תהיה פשוט להתקין Wireshark על שרת ה- HTTP, וזאת מכיוון שכל הפניות מגיעות אליו והוא פונה הלאה ל- DB, ואז מה שנבדוק זה את זמני התגובה שך ה- WEB Server וגם את אלו של השרתים הראשיים (DB ו- FILE), כאשר נקבל את התנועה שאנחנו רואים בתמונה הבאה.
וכמובן שכאן נצטרך לבדוק את שני הצדדים, ונראה איפה מתעכבת התשובה.
איך להפעיל את Transum Plugin:
להפעלת ה- Plugin (זמין בגרסאות האחרונות של Wireshark), יש להיכנס לתפריט Analyze, תחתיו ל- Enabled Protocols, ושם לאפשר את פרוטוקול Transum.
אם לא רואים את המידע עבור הקובץ שהקלטתם, יש להיכנס לתפריט Edit, תחתיו ל- Preferences, ושם תחת Protocols, כאשר נבחר ב- Transum נקבל את המידע הבא:
כאן יש להגדיר את הפרוטוקולים שאותם דוגמים, ולהוסיף את ה- Port Numbers הרלבנטיים עבור TCP ו/או UDP.
איך בודקים ועל מה להסתכל
לבדיקת זמני תגובה אפשר לעבור על התנועה של היישום ולראות, למשל ה- HTTP זה יהיה משליחת הפקודה, למשל GET, ועד קבלת התגובה מהרשת שתהיה OK. בוא נסתכל למשל על קובץ HTTP-Example. מה שאנחנו רואים זה בקשת HTTP GET ב- Packet מספר 4, ומשם מתחילה הבדיקה.
כאשר אנחנו רואים כי זמן התגובה הכולל הינו 5.88 שניות, ומתוך זה זמן 0.022 שניות זה זמן עיבוד הבקשה על השרת וזמן של 5.85 שניות זה זמן שלקח לתשובה להגיע אלינו, כלומר יש כאן בעיה ברשת שגרמה לתגובה האיטית (אנחנו רואים למשל השהייה של כ- 3 שניות בין Packets 79 ל- 80, ואם קראתם את המאמרים הקודמים באתר אתם גם יודעים מה קרה שם ..).
בואו נסתכל על קובץ נוסף – HTTP-Example-1, בדוגמא זו יש מספר TCP Connections, אבל אם נפתח את קובץ אם תפתחו חלון של IO Graph, ותגדירו פילטר של Transum.art עם MAX(Y Field) שיראה לנו גרף של זמנים (דיברתי על זה במאמר על IO Graphs), נקבל את הגרף הבא:
בגרף זה מוצגים זמני תגובה מקסימליים, ונחנו רואים שבד"כ זמני התגובה הם סבירים, אבל יש פעמיים שזמני התגובה היו כ- 400mSec, ואם נקליק על הגרף בנקודות במקסימום זה יעביר אותנו למסך הראשי, ושם נראה שאכן הייתה בעיה:
מכאן לאתר את מקור הבעיה זה כבר יותר פשוט. קודם כל, בודקים את שני ה- Peaks ב- IO Graph ורואים אם מדובר בגישה לאותו ה- URL ו/או לאותו קובץ. אם כן, יש בעיה ב- URL או באפליקציה. בכל מקרה אם רואים בעיה ב- Service time אז זאת בעיה אפליקטיבית (או חומרה או מערכת הפעלה אבל איך למצוא את זה כבר דיברנו). אם רואים בעיה ב- Response spread אז מחפשים מה קרה ברשת, למשל Retransmissions ותועות דומות, ומאיזו סיבה נגרמו.
ועוד משהו: עבור בדיקת אתרי אינטרנט יש מספר אתרים שעושים את זה לא רע בכלל. יכולים למשל לנסות את https://tools.pingdom.com/ ותראו זמני תגובה של כל אתר ממקומות שונים בעולם.
ועכשיו בואו נראה איך נראים זמני תגובה באפליקציית Database. נסתכל על קובץ DB-Example-1, וכאן נפתח את ה- IO Graph עם הפילטרים הבאים:
- art עבור זמן תגובה כולל
- st עבור זמן תגובה של האפליקציה (Service Time)
- reqspread עבור זמן בקשה של הבקשה (כאן הוקלט על השרת ורוצים לראות זמן של בקשות(
- rspspread עבור זמני תגובה של השיחה
מה שקיבלנו זה:
ומכאן אנחנו רואים זמני איטיים בבקשות, כלומר צריך לבדוק סיבה לזמני תגובה איטיים ב- Client.
סיכום:
במאמר זה דיברנו על עוד כלי נחמד ב- Wireshark. חשוב לזכור שכלי זה מגיע יחד עם יתר היכולות, וכדי לפתור בעיה יש ללכת לכל הרמות – החל מרמת ה- Ethernet, ל- IP, ל- TCP/UDP ולאפליקציה. ב- Wireshark נקבל אינדיקציות לבעיה, וכך נוכל לבודד את הבעיה ולפתור אותה.
מקווה שעזרתי ואשמח לענות לכל שאלה או בעיה.
להעשרה והרשמה לקורסים בנושא Wireshrak, עכשיו גם ב-Online:
יורם
