כיצד למדוד את מהירות הביצוע של תוכנית בלינוקס

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

בעבודה היומיומית שלנו, אנחנו לא מתעניינים רק בשאלה האם משהו "מהיר" או "איטי". אנחנו צריכים מדדים קונקרטיים: שניות, אלפיות שנייה, ואם הערך גדול מאוד, מבוטא בפורמט HH:MM:SS להבנה טובה יותר. משם, נוכל להשוות פתרונות, לזהות צווארי בקבוק, לנטר מגמות ביצועים, ובכלל, לעקוב אחר התנהגות התוכניות והשירותים שלנו.

למה אתה מעוניין למדוד זמן ביצוע בלינוקס?

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

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

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

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

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

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

מדידת זמן ביצוע באמצעות פקודת time

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

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

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

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

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

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

מדידת תזמון סקריפט Bash עם זמן וטכניקות אחרות

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

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

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

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

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

כלים למדידת פעילות הדיסק והשפעתה על הביצועים

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

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

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

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

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

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

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

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

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

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

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

מדידת זמני תגובה של האינטרנט משורת הפקודה

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

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

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

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

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

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

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

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

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

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

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

מדידת זמנים באתרי HTTPS והיבטים שיש לקחת בחשבון

במקרה של אתרים המוגשים דרך HTTPS, ישנם כמה שלבים נוספים בתהליך התקשורת שגם הם ראויים למדידה. Curl משלבת משתנים נוספים כדי להתחשב בזמן המושקע במשא ומתן על SSL/TLS וכל הפניות אפשריות.

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

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

בדיוק כמו עם HTTP, ניתן לכלול משתנים אלה בקובץ מעוצב ולעשות בהם שימוש חוזר בבדיקות שאתה מבצע מול אתרי HTTPS שונים . בדרך זו, תמיד יהיה לך דוח עקבי שמקל על השוואת תוצאות בין שרתים, דומיינים או סביבות בדיקה.

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

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

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

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

פקודות רשת שימושיות להבנת עיכובים והפסדים

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

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

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

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

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

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

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

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

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