בדיקת ביצועים ועומסים עם JMETER או K6 בעידן AI/ML | שי גינזבורג

 הקדמה

 רקע

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

 הצגת הכלים המתמודדים והיכולות שלהם

 JMeter הוא כלי (תוכנה בקוד פתוח) לבדיקת עומסים שבאמצעותו ניתן למדוד את הביצועי השרתים של אתרים ואפליקציות תוך כדי הפעלת עומסים ברמות שונות. העומסים נוצרים על ידי בוטים מתוכנתים אשר מחקים את הפעילות של גולשים אמיתיים באתר או באפליקציה שאנחנו בוחנים. Apache Jmeter כולל את כל ה-UI הנדרש על מנת להקליט את הבוטים, לעבד את ההקלטות, להריץ את הבוטים שהם הקלטות משודרגות ומשוכללות מאוד, וגם לנתח את התוצאות בזמן ובעיקר לאחר ביצוע ההרצה. האפליקציה JMeter כתובה בשפת התכנות Java, מה שהופך אותה לבלתי תלויה בפלטפורמה ונגישה באופן נרחב. במקרים רבים אפשר להקליט וגם לתכנת בנוחות רבה את הבוטים על לפטופ בסביבת Windows ואחר כך להריץ את אותם בוטים מתוך שרתים בסביבת Linux על גבי ענן פרטי, ציבורי, או היברידי. האפליקציה JMeter מספקת לנו את כל ה-UI שמתורגם לפקודות של Java, כלומר העומס נוצר מתוך פקודות של הקוד גם אם אנחנו לא יודעים לתכנת בשפה זאת, אבל יודעים להשתמש בכל ה-UI של Jmeter. הכלי הזה מתאים גם לבדיקות אוטומטיות פונקציונלית ובדיקות רגרסיה, שאינן קשורות לממשק הגרפי בצד הלקוח שהוא הדפדפן הרגיל שלנו ברוב המקרים, כי בבדיקות עומסים אין דפדפן שעושה Rendering בתוך חלון, וכל בוט צריך לחיות בתוך מרחב בזיכרון שאין לו פנים גרפיות. לא נוכל לקיים סוג של קשר עין עם כל בוט בגלל שאנחנו רוצים להריץ אלפים כאלה בו זמנית. כל בוט הוא Thread נוסף שמנוהל בתוך מכונה וירטואלית Java Virtual Machine אשר מתקיימת על גבי מערכת ההפעלה של הפלטפורמה המארחת. לשם השוואה והבהרה, כל Web Browser תופס כמעט Core שלם על מנת לפעול, וכמובן שאם אנחנו רוצים לבדוק למשל מיליון יוזרים הפועלים בו זמנית, לא נוכל להקצות משאבים הכוללים מיליון Cores לטובת אף בדיקה, כי זה אינו מציאותי, ולכן ניפרד כבר כאן כידידים מהדפדפן כאשר אנחנו נכנסים לעולם בדיקות העומסים.

תמונה 1 – הממשק של JMeter בסיסי מאד אז זהו המעט שמחזיק את המרובה

המטרה המקורית בפיתוח הראשוני של JMeter הייתה הרצת בוטים בפרוטוקול HTTP בלבד לצורך בדיקת אתרי אינטרנט פשוטים, אך מאז הכלי התרחב מאוד מבחינת תמיכה בפרוטוקולים רבים אחרים (כולל JDBC, FTP, ועוד) ונוספו גם פונקציות משוכללות, דו"חות, תיעוד רב, ויכולות בדיקה רבות אחרות. JMeter מצטיין בהדמיית עומסים כבדים על יישומים כדי להעריך את הביצועים שלהם תחת עומסים כבדים. מעבר לבדיקת עומסים, הוא יכול גם לאמת את נכונות הפונקציונליות של האפליקציה, והוא מתאים מאוד לבדיקות רגרסיה פונקציונלית. הרצת הבדיקה יכולה להיות מבוזרת, כלומר אפשר לבצע בדיקת עומסים מתוך מספר שרתים בו-זמנית, מה שהופך את הכלי למתאים במיוחד לבדיקת תרחישים בקנה מידה גדול ממש. JMeter כולל ממשק משתמש גרפי (GUI) ליצירה, הקלטה, הרצה וניהול של תוכניות בדיקה. הממשק מיושן ובסיסי מאד, אבל הוא מקצועי ואמין, כך שבודקים יכולים לעצב תרחישי בדיקה באופן ויזואלי, להוסיף דגימות, להגדיר מאזינים Listeners ולהגדיר נקודות בדיקה Assertions, ועוד. הסקריפטים של JMeter הם קובצי XML, שניתן לערוך, לשלוט בגרסה שלהם, ולשתף בין צוותים. מבחינת תוספים והרחבה, JMeter בעל מערכת אקולוגית עשירה של תוספים והרחבות רבות, אשר זוכות לעדכונים מדי מספר חודשים. משתמשים יכולים לשדרג את הפונקציונליות על ידי התקנת תוספים נוספים או כתיבת תוספים חדשים לאחר התאמה אישית. מבחינת קהילה ותיעוד, ל-JMeter יש קהילה פעילה התורמת לפיתוח ולתחזוקה של הקוד הפתוח. קיים באינטרנט תיעוד רב ומקיף, הדרכות ופורומים זמינים למשתמשים. JMeter נמצא בשימוש נרחב לבדיקת עומס יישומי אינטרנט, ממשקי API ושירותי אינטרנט. הוא יכול גם להתחבר ישירות אל בסיסי נתונים אשר תומכים בפרוטוקול JDBC ואז לדמות שאילתות ישירות אל מסד נתונים, ולמדוד זמני תגובה בלי לעבור דרך כל הטופולוגיה ודרך שרתי האינטרנט. JMeter משתלב למעשה עם כל כלי ניטור לאיסוף מדדי ביצועים.

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

עכשיו נתעמק במתמודד השני שלנו...

k6 הוא כלי בדיקת עומסים ממוקד מפתחים. גם כלי זה נכתוב בקוד פתוח והוא מיועד לבדיקות ביצועים והערכת מדרגיות (Scalability), כלומר בדיקות ביצועים ברמות מדורגות של עומסים אשר הולכים וגדלים משלב לשלב. בניגוד לכלים אחרים, k6 כתוב בשפת התכנות Go (Golang), ואינו דורש סביבת Java או הקמת מכונת Java וירטואלית על מנת להריץ אותו - עובדה שתורמת ליעילות הכלי ולביצועים שלו, כלומר, מבחינה תיאורטית לפחות, אנחנו אמורים להפיק עומס רב יותר על גבי חומרה זהה בזכות העובדה, שהכלי המחולל את העומס מתוכנן באופן חסכוני למדי, לכאורה. k6 מעניק עדיפות לחוויית המפתח, מה שהופך אותו לכלי מועדף על משתמשים בעלי ידע טכנולוגי. כלומר, חוסר ה-GUI שלו מונע מאנשי QA רבים לנסות אותו בכלל, כי קשה לציבור הזה להתמודד עם כלי שאין לו חלון ידידותי, אלא דורש הקלדה של פקודות ארוכות בממשק ה-Terminal. מצד שני, המפתחים של הכלי הזה מכוונים אותו כנראה בעיקר לבדיקות אימות פיתוח, כך שהקמת GUI למוצר שלהם אינה נמצאת ככל הנראה ברשימת המשימות שלהם. ישנם היבטים מרכזיים של k6 שאנחנו חייבים להכיר, למשל, בניגוד ל-Jmeter, שהתסריטים שלו הם קבצים סטנדרטיים של XML, אז סקריפטים של k6 נכתבים בשפת JavaScript. מפתחי התסריטים יכולים ליצור תרחישי בדיקה אשר ניתנים לשימוש חוזר ומודולרי. בנושא ביצוע מקבילי (בו-זמנית) של משתמשים וירטואליים (Virtual Users), k6 מריץ מספר איטרציות במקביל, וכך הוא מדמה VUs. VUs פועלים כמו לולאות מקבילות בזמן, ומבצעות תרחישי בדיקה במקביל. מבחינת התמקדות בתרחישים של גולשים אמיתיים - k6 בנוי לבצע תרחישים מציאותיים של בדיקת עומס. מפתחים יכולים לפרק בדיקות גדולות לחתיכות קטנות יותר לשימוש חוזר. ראוי לציין גם, שבניגוד לבדיקות המבוזרות עם JMeter - הבדיקות של 6k מבצעות מתוך מכונה אחת. זה אמנם מפשט את ההגדרות והביצוע של ההרצות, אבל זה בהחלט אינו יתרון תחרותי מבחינת תקרת הביצועים כמובן.  מבחינת מקרי שימוש, הרי שהכלי k6 מתאים היטב לבדיקת יישומי אינטרנט, ממשקי API ומיקרו-שירותים , וזה די חופף לכל מועמד אחר שנבדוק בעצם. מבחינת אינטגרציה מתמשכת (CI/CD),k6  משתלב בצורה חלקה עם תהליכים כאלה, וכך המפתחים יכולים להפוך את בדיקות הביצועים לאוטומטיות, כלומר לקבוע אותן כחלק מתהליך העבודה בפיתוח שלהם. הניסיון מראה, שהתכונה הזאת אינה רבת משמעות, מכיוון שההבדלים בביצועים בין גרסה לגרסה הם זניחים, אלא אם כן בוצע שינוי מהותי בארכיטקטורה של האפליקציה. למעשה, נכון לבדוק ביצועים ועומסים מספר פעמים בפיתוח, אבל להטמיע את זה לתוך ה-CI זה לא תמיד רעיון מוצדק מבחינת ניצול משאבים הגיוני ברמת ניהול הסיכונים בפרויקט פיתוח. ל-k6 יש קהילה הולכת וגדלה של משתמשים ותורמים. קל למצוא באינטרנט תיעוד רב ומקיף ומדריכים זמינים למשתמשים. הקהילה כמובן צעירה וקטנה יותר בהשוואה לזאת של JMeter.

תמונה 2 – 6k חסר ממשק גרפי GUI אך עמוס ביכולות של בדיקת עומסים לתוכנה

 לסיכום, החוזקות של k6 נעוצות בגישה הידידותית למפתחים, בביצוע מקבילי ובהתמקדות בתרחישים מציאותיים. זוהי בחירה מצוינת עבור יישומים ומיקרו-שירותים מודרניים. בניגוד ל-JMeter, ל-k6 חסר ממשק משתמש גרפי, וכמו-כן, המשתמשים חייבים להיות בעלי יכולת עבודה עם סקריפטים מבוססי קוד בשפת JavaScript. בעוד ש- k6 תומך בפרוטוקולים נפוצים (HTTP, WebSocket), הוא לא מכסה בינתיים את כל הרשימה הנרחבת של JMeter.

 הכרות מעשית עם חוזקות הכלים לבדיקות עומסים וביצועים

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

https://demo.guru99.com/test/newtours/

כדי להתקין Jmeter, נכין קודם מכונת Java – קל מאוד להוריד גרסה מעודכנת מהאתר:

https://www.java.com/en/download/

 ואז רק לפתוח קובץ ZIP מהאתר של Jmeter:

https://jmeter.apache.org/download_jmeter.cgi

לאחר ההורדה, פותחים את קובץ ה-ZIP, ואם אתם עובדים למשל בסביבת חלונות, תמצאו בתוך תיקיית BIN את קובץ ההפעלה jmeter.bat. כעת נתקין גם את k6 בקלות רבה. פותחים חלון Terminal ובתוכו כותבים את הפקודה

winget install k6 --source winget

 כדי לתרגל בקלות את שני הכלים, הכנתי עבורכם דוגמאות שקל להוריד ולהריץ על המחשב שלכם לאחר ההתקנה. הקישור להורדות הוא:

https://github.com/sginsbourg/jmeter-vs-k6-2024

לאחר ההתקנה של הכלים וההורדה של הדוגמאות, נסו להריץ אותם ואף לשדרג את התסריטים. למשל, נסו לבדוק כיצד ניתן להוסיף Assertion שמוודא שאכן התקבל סטטוס 200 OK בכל אחת מהדוגמאות. אבל אל תעצרו כאן, כי יש שרתים ששולחים סטטוס הצלחה גם יחד עם עמודי שגיאה (מכיוון שעמוד השגיאה נמסר בעצמו מהשרת ללקוח בהצלחה). לכן, נסו להוסיף ולידציה נוספת אחרת וחד-משמעית, לדוגמא, מחרוזת טקסט ספציפית שלא תופיע בעמוד שגיאה בשום אופן. מצד שני, נסו אפילו להוסיף ולידציה שלילית (הפוכה), כלומר, הוסיפו תנאי שמחרוזת שגיאה נפוצה לא תופיע בתשובה של השרת.

 כשאתם מתנסים עם Jmeter, תוכלו לפתוח את קובץ הדוגמא example.jmx מתוך הממשק של הכלי. כזכור, אין ממשק ל- k6. במקרה זה תריצו את הדוגמא example.js מתוך שורת הפקודה הבאה: k6 run example.js ואם תרצו לערוך את התסריט אז בניגוד ל- Jmeter, עם k6 תצטרכו לפתוח כל עורך טקסטים, למשל Notepad.

 את הנושא של ביטויים רגולריים REGEX ואת הטיפול הנדרש בפרמטרים דינמיים נשאיר למסגרת אחרת (למשל, המקרה שבו הלקוח מקבל מהשרת "Session ID" חד-פעמי חדש אחרי כל לוג-אין מוצלח בתוךResponse Header, והוא צריך להשתמש בו בתוך כל Request Header בכל המשך השימוש באפליקציה, אחרת השרת יזרוק אותו שוב לעמוד הכניסה). נציין רק, שבהעדר דפדפן (כמו שהסברתי קודם) נצטרך לטפל בכל אלמנט מהותי שבבדיקות אוטומטיות ברמת ממשק המשתמש של הדפדפן (GUI) טופל על ידי הדפדפן בעצמו. תוכלו להמשיך לשחק בדוגמאות שהכנתי עבורכם ולחפש למשל, היכן קובעים את מספר הגולשים הווירטואליים, את מספר מחזורי הבדיקה, את זמן ההמתנה בין דגימה לדגימה, וכל פרמטר אחר שמעניין אותכם להכיר. ככל שתתעמקו ותתנסו בשני הכלים, תשדרגו את המקצועיות שלכם ואת היכולות הטכניות שלכם.

 חשוב מאד - במיוחד אם אתם מריצים את הכלים ואת הדוגמאות על מחשב פרטי ולא על שרת עוצמתי בענן, שימו לב לניצול המשאבים של המחשב אשר מפיק את העומס. אם המשאבים המקומיים של המחשב מוצו (למשל, CPU 100% עסוק, או צריכת זיכרון RAM מקסימלית, או שימוש ברשת ללא רוחב פס משמעותי) אז כל התוצאות של בדיקות העומס יהיו גרועות, אבל זה נובע רק מחוסר תיכנון המשאבים המקומיים ולא קשור לביצועים של האפליקציה בכלל כמובן.

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

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

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

 מתאם (Correlation) וחילוץ נתונים (Extraction) מתוך פלט בצד השרת: בינה מלאכותית יכולה לזהות מתאמים (קורלציות) בין בקשות ותגובות, ועוזרת לבודקים לחלץ את הנתונים הדרושים (למשל, Verification Tokens, Cookies) עבור בקשות עוקבות. התהליך הזה יפחית את המאמץ הידני בזיהוי וטיפול בערכים דינמיים.

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

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

 תחזוקת סקריפט: AI יכול לעקוב אחר שינויים באפליקציה ולעדכן אוטומטית סקריפטים לבדיקה. הוא מזהה קישורים 'שבורים' (404), נקודות קצה (End Points) שהוצאו משימוש או פרמטרים שהשתנו.

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

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

מסקנות לסיכום ובחירת הכלי הנכון לבדיקות עומסים וביצועים

לסיכום, החוזקות של JMeter נעוצות בריבוי ההרחבות שלו (כמעט כולן Free Open Source), בתמיכה בפרוטוקולים מגוונים (לא רק Http/s), ממשק ידידותי למשתמש (אפילו שנראה מיושן) וכלי דיווח חזקים (Offline Report & Analysis). בסופו של יום, זהו כלי אמין עבור אנשי מקצוע בתחום איכות התוכנה וספקי שירותי בדיקות ביצועים. הכלי מתאים לבדיקות של סביבה יחסית עתירת משאבים – הוא צורך יותר זיכרון הודות לארכיטקטורה מבוססת Java. השתמשו ב-  JMeter כאשר החוזקות שלו משתלבות עם הצרכים שלכם, וכאשר אתם אנשי QA אשר צריכים להתחיל לבדוק במהירות ואז להפיק ממצאים כדי לקדם את הפרויקט. הכלי הוא אופטימלי למצבים שבהם נדרש לכם כלי בעל GUI. החוזקות של k6 הן סקריפטים ידידותיים למפתחים בשפת JavaScript, ביצוע מקבילי, יכולת הדמיה של תרחישים מציאותיים וגישה מודרנית לבדיקות מבחינת שילוב עם CI/CD. השתמשו ב-k6 כאשר אתם מעדיפים את חוויית המפתחים, למשל בבדיקות אימות הפיתוח, לפני המסירה לאנשי QA, ומעדיפים סקריפטים מבוססי קוד JavaScript. הכלי הזה אידיאלי לצוותים בעלי ידע טכנולוגי, אנשי פיתוח, ולמי שמחפש מדרגיות (Scalability). הכלי מתאים מאוד לבדיקות עומס של אפליקציות ומיקרו-שירותים מודרניים.

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