streamalism.org

1. הקדמה

הפופולריות הגוברת של יישומים ומיקרו-שירותים שמקורם בענן מייצרת ביקוש מוגבר למכלי servlet משובצים. Spring Boot מאפשר למפתחים לבנות בקלות יישומים או שירותים באמצעות 3 המכולות הבוגרות ביותר שיש: Tomcat, Undertow ו- Jetty.

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

2. תלות

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

באופן כללי, אנו רוצים לציין את ההורה שלנו כ- אביב-אתחול-המתנע-הורהואז לכלול את המתחילים שאנחנו רוצים:

 org.springframework.boot spring-boot-starter-parent 2.2.2.RELEASE org.springframework.boot spring-boot-starter org.springframework.boot spring-boot-starter-web 

2.1. טומקט

אין צורך בתלות נוספת בעת השימוש ב- Tomcat מכיוון שהוא נכלל כברירת מחדל בעת השימוש קפיץ-אתחול-רשת.

2.2. מֵזַח

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

ואז, אנחנו פשוט מכריזים על תלות ב אביב-מגף-סטרטר-מזח:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-tomcat org.springframework.boot spring-boot-starter-jetty 

2.3. זֶרֶם תַחתִי

הגדרת Undertow זהה ל- Jetty, אלא שאנו משתמשים בה קפיץ-אתחול-התחלה-מתחילה כתלות שלנו:

 org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-tomcat org.springframework.boot spring-boot-starter-undertow 

2.4. מַפעִיל

אנו נשתמש במפעילים של Spring Boot כדרך נוחה להדגיש את המערכת ולשאול למדדים.

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

 org.springframework.boot spring-boot-starter-actuator 

2.5. ספסל אפאצ'י

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

משתמשי Windows יכולים להוריד את אפאצ'י מאחד מספקי הצד השלישי המקושרים כאן. אם אפאצ'י כבר מותקן במחשב Windows שלך, אתה אמור להיות מסוגל למצוא ab.exe שלך אפאצ'י / סל מַדרִיך.

אם אתה נמצא במכונת לינוקס, ab ניתן להתקין באמצעות apt-get עם:

$ apt-get להתקין apache2-utils

3. מדדי הפעלה

3.1. אוסף

על מנת לאסוף את מדדי ההפעלה שלנו, נרשום מטפל באירועים שיופעל על Spring Boot ApplicationReadyEvent.

נשלוף באופן פרוגרמטי את המדדים שאנו מעוניינים בכך על ידי עבודה ישירה עם ה- מד רישום משמש רכיב המפעיל:

@Component class class StartupEventHandler {// logger, constructor private String [] METRICS = {"jvm.memory.used", "jvm.classes.loaded", "jvm.threads.live"}; מחרוזת פרטית METRIC_MSG_FORMAT = "מדד הפעלה >> {} = {}"; מטר רישום פרטי מטר רישום; @EventListener חלל ציבורי getAndLogStartupMetrics (אירוע ApplicationReadyEvent) {Arrays.asList (METRICS) .forEach (זה :: getAndLogActuatorMetric); } תהליך ריק ריק פרטיMetric (מדד מחרוזת) {Meter meter = meterRegistry.find (metric) .meter (); סטטיסטיקות מפה = getSamples (מטר); logger.info (METRIC_MSG_FORMAT, מדד, stats.get (Statistic.VALUE) .longValue ()); } // שיטות אחרות}

אנו נמנעים מהצורך לבצע שאילתות ידניות על נקודות קצה של Actuator REST או להריץ קונסולת JMX עצמאית על ידי רישום מדדים מעניינים בהפעלה בתוך מטפל האירועים שלנו.

3.2. בְּחִירָה

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

• jvm.memory.used - סך הזיכרון בו השתמש ה- JVM מאז ההפעלה
• jvm.classes.loaded - המספר הכולל של שיעורים שנטענו
• jvm.threads.live - המספר הכולל של האשכולות הפעילים. במבחן שלנו, ניתן לראות ערך זה כמניין החוטים "במנוחה"

4. מדדי זמן ריצה

4.1. אוסף

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

על מנת לבדוק יישום אמיתי בעומס, אנו עשויים להשתמש בנקודות קצה המסופקות על ידי היישום שלנו.

לאחר שהשרת התחיל, נקבל שורת פקודה ונבצע ab:

ab -n 10000 -c 10 // localhost: 8080 / מפעיל / מדדים

בפקודה לעיל, ציינו סך של 10,000 בקשות באמצעות 10 שרשורים מקבילים.

4.2. בְּחִירָה

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

לענייננו, התמקדנו בבקשות לשנייה ובזמן לפי בקשה (ממוצע).

5. תוצאות

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

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

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

6. דיון בנצ'מרק

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

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

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

בנוסף, פיתרון ביצועים מתוחכם יותר כמו JMeter או Gatling יניב ככל הנראה תובנות בעלות ערך רב יותר.

7. בחירת מיכל

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

8. מסקנה

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

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

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