streamalism.org

1. הקדמה

בחירת הכלי המתאים לתפקיד יכולה להיות מרתיעה. במדריך זה נפשט זאת על ידי השוואה בין שלושה כלי בדיקת עומסי יישומי אינטרנט - Apache JMeter, Gatling ו- The Grinder - מול ממשק API פשוט של REST.

2. כלי בדיקת עומסים

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

2.1. גטלינג

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

2.2. JMeter

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

בקרו במדריך מבוא ל- JMeter לקבלת צילומי מסך והסבר נוסף.

2.3. המטחנה

והכלי הסופי שלנו, The Grinder, מספק מנוע סקריפטים מבוסס-תכנות יותר משני האחרים ומשתמש בג'יתון. עם זאת, ל- Grinder 3 יש פונקציונליות להקלטת תסריטים.

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

3. הגדרת מקרה הבדיקה

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

• להוסיף / לעדכן רשומת תגמולים
• צפו בשיא הפרסים / כל התגמולים
• לקשר עסקה לרשומת תגמולי לקוח
• צפו בעסקאות לרשומת תגמולי לקוח

התרחיש שלנו:

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

לאחר מכן, אנו מבררים את העסקאות.

3.1. ה- API של REST שלנו

בואו נקבל הדגשה מהירה של ה- API על ידי צפייה בכמה מתכונות השיטה:

@PostMapping (path = "/ rewards / add") @ResponseBody RewardsAccount addRewardsAcount (@RequestBody RewardsAccount body) @GetMapping (path = "/ rewards / find / {customerId}") public @ResponseBody optionCustomer (@PathVariable Integer customerId) @ PostMapping (path = "/ עסקאות / הוספה") ציבורי @ ResponseBody Transaction addTransaction (@RequestBody Transaction Transaction) @ GetMapping (path = "/ actions / findAll / {rewardId}") public @ResponseBody Iterable findTransactions (@PathVariable Integer rewardId) 

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

היישום הנבדק משתמש גם במסד נתונים H2 בזיכרון לצורך התמדה.

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

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

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

כדי להשיג השוואה הוגנת, נבצע את אותם שלבי האוטומציה לכל כלי:

1. צור מזהי חשבון לקוח אקראיים
2. פרסם עסקה
3. מנתח את התגובה עבור מספר הלקוח האקראי ומזהה העסקה
4. שאילתת לקוח מתגמלת את מזהה החשבון עם מזהה הלקוח
5. ניתח את התגובה עבור מזהה חשבון התגמולים
6. אם לא קיים מזהה חשבון תגמולים, הוסף אחד עם פוסט
7. פרסם את אותה העסקה הראשונית עם מזהה תגמולים מעודכן באמצעות מזהה העסקה
8. שאילתה לכל העסקאות לפי מזהה חשבון תגמולים

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

3.3. גטלינג

עבור Gatling, היכרות עם Scala מוסיפה יתרון למפתחים מכיוון ש- API של Gatling הוא חזק ומכיל הרבה תכונות.

ה- API של גטלינג נוקט בגישת DSL של בונה, כפי שניתן לראות בשלב 4 שלה:

.exec (http ("get_reward") .get ("/ rewards / find / $ {custId}") .check (jsonPath ("$. id"). saveAs ("rwdId"))) 

יש לשים לב במיוחד לתמיכה של גאטלינג ב- JSON Path כשאנחנו צריכים לקרוא ולאמת תגובת HTTP. כאן נבחר את מזהה התגמול ונשמור אותו במצבו הפנימי של גטלינג.

כמו כן, שפת הביטוי של גאטלינג מאפשרת לגשת בקשות דינמיות מיתרים:

.body (StringBody ("" "{" customerRewardsId ":" $ {rwdId} "," customerId ":" $ {custId} "," transactionDate ":" $ {txtDate} "}" "")). asJson) 

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

val scn = תרחיש ("RewardsScenario"). חזור על (1000) {...} setUp (scn.inject (atOnceUsers (100))). פרוטוקולים (httpProtocol)

ניתן לראות את כל סקריפט סקאלה ברפיו של Github.

3.4. JMeter

JMeter מייצר קובץ XML לאחר תצורת ה- GUI. הקובץ מכיל אובייקטים ספציפיים ל- JMeter עם מאפייני קבוצה וערכיהם, למשל:

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

התצורה שלנו עבור ריצות ומשתמשים בשימוש ב- JMeter ThreadGroups:

100

צפה בכל כולו jmx קובץ כהפניה. אם אפשר, כתיבת מבחנים ב- XML ​​כ- .jmx קבצים אינם הגיוניים באמצעות ממשק משתמש מלא עם כל התכונות.

3.5. המטחנה

ללא התכנות הפונקציונאלי של Scala ו- GUI, התסריט של ג'יתון ל- The Grinder נראה די בסיסי. הוסף כמה שיעורי Java של המערכת, ויש לנו הרבה פחות שורות קוד.

customerId = str (random.nextInt ()); result = request1.POST ("// localhost: 8080 / עסקאות / הוסף", "{" '"customerRewardsId"': null, "'" customerId "'": "+ customerId +", "'" transactionDate "' ": null}") txnId = parseJsonString (result.getText (), "id")

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

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

grinder.threads = 100 grinder.processes = 1 grinder.runs = 1000

התסריט המלא של ג'יתון שלנו עבור The Grinder ייראה כך.

4. ריצות מבחן

4.1. ביצוע מבחן

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

כדי להריץ את הבדיקות, נשתמש בגטלינג קוד פתוח בגרסת 3.4.0 ככלי עצמאי, JMeter 5.3 ו- The Grinder גרסה 3.

Gatling דורש רק שיש לנו JAVA_HOME ו GATLING_HOME מַעֲרֶכֶת. כדי לבצע Gatling אנו משתמשים:

./gatling.sh

בספריית GATLING_HOME / bin.

JMeter זקוק לפרמטר כדי להשבית את ממשק המשתמש לבדיקה כפי שמתבקש בעת הפעלת ה- GUI לתצורה:

./jmeter.sh -n -t TestPlan.jmx -l log.jtl

כמו Gatling, The Grinder דורש שנקבע JAVA_HOME ו GRINDERPATH. עם זאת, הוא זקוק לעוד כמה מאפיינים:

ייצא CLASSPATH = / home / lore / Documents / grinder-3 / lib / grinder.jar: $ CLASSPATH export GRINDERPROPERTIES = / home / lore / Documents / grinder-3 / דוגמאות / grinder.properties

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

לבסוף, אנו מתחילים את הקונסולה ואת הסוכנים באמצעות:

java -classpath $ CLASSPATH net.grinder.Console

java -classpath $ CLASSPATH net.grinder. Grinder $ GRINDERPROPERTIES

4.2. תוצאות מבחן

כל אחת מהבדיקות רצה 1000 ריצות עם 100 משתמשים / שרשורים. בואו נפרק כמה מהדגשים:

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

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

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

בעת שימוש ב- JMeter, אנו יכולים לפתוח את ה- GUI לאחר הפעלת הבדיקה וליצור דוח HTML המבוסס על קובץ היומן איפה שמרנו את התוצאות:

דוח ה- JMeter HTML מכיל גם פירוט של הסטטיסטיקה לכל בקשה.

לבסוף, מסוף המטחנות מתעד נתונים סטטיסטיים עבור כל סוכן ומפעיל:

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

5. סיכום

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

גטלינג:

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

JMeter:

• ממשק API חזק (באמצעות GUI) לפיתוח סקריפט בדיקה ללא קידוד
• תמיכה בקרן אפאצ'י ושילוב נהדר עם Maven

המטחנה:

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

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

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

JMeter הוא הכלי לוגיקה עסקית מסובכת או שכבת שילוב עם סוגי הודעות רבים. כחלק מ- Apache Software Foundation, JMeter מספקת מוצר בוגר וקהילה גדולה.

6. מסקנה

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

לבסוף, ניתן למצוא את ה- API והסקריפטים ב- Github.