כשיש לנו בעיות ביצועים בקוד, אחד הכלים הראשונים שכדאי להכיר הוא Apache HTTP server benchmarking tool או בקיצור benchmark testing. הכלי הזה מאוד רלוונטי לכל אפליקציה או אתר שיושבים על LAMP – שזה רוב האתרים כיום בעולם. יש כלים אחרים, טובים ומשוכללים יותר שמתאימים לעוד stacks ולא רק ל-LAMP, אבל לכלי הזה יש שני יתרונות חשובים: היתרון הראשון הוא שהוא חינמי לחלוטין. היתרון השני הוא שהוא ממש פשוט לשימוש, בטח ובטח לשימוש בסיסי.
מה הכלי הזה עושה? מדמה המון המון קריאות לשרת, חלק מהקריאות אמורות להיות באותו הזמן. אחרי שהכלי מבצע את כל הקריאות, הוא עושה ניתוח סטטיסטי ואומר לנו כמה זמן ממוצע לקח לכל קריאה להיות מושלמת (כלומר לדף לעלות), מה החציון של הקריאה ומה העשירונים הגבוהים של הקריאות – כלומר הוא משמש מדד די טוב למדידת הביצועים. אם למשל פיתחתי תוסף לוורדפרס והכל נראה סבבה, אבל אני רואה שה-Time per request – הזמן שלקח לנו לקבל קוד 200 – עלה מ-400 מילישניות ל 1,000 מילישניות – סימן שאני בבעיה. כמובן שזה תלוי בתוסף ובמערכת – אין כמעט תוסף שלא יוסיף כמה מילישניות, אבל יש הבדל בין דרדור של אחוז בביצועים לבין דרדור של 100 אחוז ויותר.
כאשר עושים בכלי הזה שימוש נבון, אפשר לחסוך המון בעיות מראש. לא מעט אתרים עובדים מעולה כששלושה או ארבעה אנשים גולשים אליהם, אבל ברגע שהם עולים לסביבה החיה הם מתחילים לזייף כיוון שיש כמה וכמה גולשים שנכנסים אליהם. מאוד לא נעים להתחיל לעבוד תחת לחץ מלקוח זועם שהאתר שלו נופל בכל פעם שיש הרבה אנשים. בנוסף, הבדיקות האלו יכולות לסייע לנו במידה ויש לנו hosting בעייתי או חיבור בעייתי בינינו לבין ה-hosting. אם ה-benchmark בסביבת הפיתוח תקין לחלוטין אבל האתר לא סוחב – זה בדרך כלל בעיה של רשת או של hosting.
את ה-benchmark testing אני נוהג לבצע בדרך כלל ישירות על סביבת הפיתוח ולא על שרת מרוחק. זה על מנת לנטרל בעיות של רשת שיכולות להתקיים. אני משתדל שהמחשב שמבצע את הבדיקות יהיה סביר, לא יסבול מעומס ולא מריץ עליו דברים במקביל להרצת הבדיקה.
אז איך מריצים? אני כמובן יוצא מנקודת הנחה שסביבת הפיתוח שלכם מבוססת על לינוקס ולא על איזה תפלצת מיקרוסופטית מוזרה שבמקרה הותקן עליה PHP.
אם יש לכם חלונות או משהו כזה, תעשו לעצמכם טובה, תשרפו את התועבה ותתקינו סביבת עבודה נורמלית. אבל אם אתם ממש ממש מתעקשים, אז באופן עקרוני אפשר להריץ את זה על חלונות.
בכל מקרה, ההרצה היא די פשוטה:
ab -n 100 -c 5 http://mysite.dev/?p=10
מה זה אומר? זה אומר שהכלי יעשה 100 בקשות מחמישה "משתמשים" שהם בעצם threads שונים. כל חמש מאות הבקשות יתועלו אל: http://mysite.dev/?p=10. שימו לב שאם מדובר ב-virtual host עם שם שנתתם בעצמכם (כמו למשל internet-israel.dev.il שהוא השם של גרסת הפיתוח של אתר זה במכונה שלי), אז חובה להכניס את שם המתחם לקובץ ה-hosts.
שימו לב שאם אתם לא משתמשים ב-GET – חובה לשים / אחרי הכתובת. למשל /http://example.com.
אחרי פרק זמן מסוים, אנחנו נקבל את התוצאות:
Server Software: Apache/2.4.7
Server Hostname: mysite.dev
Server Port: 80
Document Path: /?p=10
Document Length: 12562 bytes
Concurrency Level: 50
Time taken for tests: 102.291 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 12865000 bytes
HTML transferred: 12562000 bytes
Requests per second: 9.78 [#/sec] (mean)
Time per request: 5114.526 [ms] (mean)
Time per request: 102.291 [ms] (mean, across all concurrent requests)
Transfer rate: 122.82 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.1 0 11
Processing: 733 5078 1515.8 4786 13425
Waiting: 599 4097 1138.2 3871 11915
Total: 735 5079 1515.6 4786 13435
Percentage of the requests served within a certain time (ms)
50% 4786
66% 4854
75% 4907
80% 4964
90% 6403
95% 8451
98% 10998
99% 12211
100% 13435 (longest request)
זה דו"ח הבדיקה המלא. הוא נראה קצת מפחיד, אבל אם נסתכל עליו יותר מקרוב נראה שהוא ממש לא נורא:
Server Software: Apache/2.4.7
Server Hostname: mysite.dev
Server Port: 80
Document Path: /?p=10
Document Length: 12562 bytes
החלק הזה הוא מידע טכני על הבדיקה. אין כאן משהו שיפיל אתכם – הוא פשוט מציין את הבדיקה עצמה.
Concurrency Level: 50
Time taken for tests: 102.291 seconds
Complete requests: 1000
Failed requests: 0
Total transferred: 12865000 bytes
HTML transferred: 12562000 bytes
Requests per second: 9.78 [#/sec] (mean)
Time per request: 5114.526 [ms] (mean)
Time per request: 102.291 [ms] (mean, across all concurrent requests)
Transfer rate: 122.82 [Kbytes/sec] received
החלק הזה גם מכיל נתונים על הבדיקה מהזוית של סך הכל. מדובר פה על מספר המשתמשים (כלומר מספר ה-threads) ומספר הבקשות שהצליחו ושנכשלו. יש את גודל המידע – הן קובץ ה-HTML והן קובץ ה-HTML וה-headers (לכל בקשת HTTP יש גם headers שבאים איתה).
מה שמעניין הוא שני הנתונים תחת Time per request – השני הוא mean, across all concurrent requests – זה הזמן הממוצע לבקשה. כלומר אם יש לי 1,000 בקשות שבוצעו על ידי 50 משתמשים (שהם threads, לא משתמשים אמיתיים) כל בקשה לקחה 102.291 מילישניות בממוצע.
והנתון Time per request:[ms] (mean) ? זה הממוצע של כל הבקשות למשתמש אחד. אם ניקח את הנתון mean, across all concurrent requests ונכפיל אותו במספר המשתמשים, נקבל את המספר הזה.
Transfer rate מאוד לא מעניין כאשר אנו עוסקים במכונה מקומית.
הטבלה הבאה היא עיקר המידע:
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.1 0 11
Processing: 733 5078 1515.8 4786 13425
Waiting: 599 4097 1138.2 3871 11915
Total: 735 5079 1515.6 4786 13435
הטורים בטבלה הם: הבקשה המהירה ביותר (min), הממוצע (mean), סטיית התקן ([+/-sd]), החציון (median) והבקשה האיטית ביותר (max). אנחנו בדרך כלל מסתכלים על הממוצע והחציון. כאשר השאיפה היא שהם יהיו נמוכים ככל האפשר. שונות גבוהה (שמתבטאת גם בפער גדול בין הממוצע לחציון) יכולה להצביע על בעיה גדולה במספר רב של משתמשים/בקשות.
השורות בטבלה הן הזמן המוקדש לחיבור שבדרך כלל יהיה אפס. השורה של Processing היא הזמן שלקח לשרת לעבד את הבקשה ולהגיש אותה בשלמותה. ה-waiting הוא הזמן שלקח לשרת לעבד את הבקשה בלבד (הזמן שנמדד מרגע קבלת הבקשה ועד הגשת הביט הראשון). ה-total הוא סך הזמן שלקח לבקשה מרגע השליחה ועד רגע קבלת כל המידע – זו סכימה של ה-connect (הזמן שלקח לבקשה להגיע) וה-processing (עיבוד ושליחת המידע המלאה).
אם יש לנו הפרש גדול בין ה-waiting ל-processing, סימן שהוא שולח המון מידע בבקשה שלו. אם יש לנו processing גדול מדי, סימן שהשרת עובד קשה ויש לנו בעיית יעילות.
הטור האחרון מתרכז בשונות ומראה על אחוז הבקשות שהוגשו בזמן מסוים
Percentage of the requests served within a certain time (ms)
50% 4786
66% 4854
75% 4907
80% 4964
90% 6403
95% 8451
98% 10998
99% 12211
100% 13435 (longest request)
למשל, 50 אחוז מהבקשות הושלמו תוך 4786 מילישניות או פחות. 80 אחוז מהבקשות הושלמו תוך 4964 מילישניות או פחות. מן הסתם הנתון של הבקשה האיטית ביותר (max) שהופיע בטבלה יופיע כאן בתור הבקשה הארוכה ביותר שכל הבקשות (100 אחוז מהן) הוגשו במהירות שלה או פחות.
אפשר לעשות עוד דברים עם ה-Apache Benchmark. אפשר ליצור עוגיות (כאן יש סקריפט שמראה איך) וליצור משתני POST. אחד היתרונות של הכלי הזה – חוץ מזה שהוא חינמי ופשוט זה שהמון אנשים משתמשים בו (כי הוא חינמי ופשוט…) ואז יש המון מדריכים ועזרה.
כאמור מדובר באחד הכלים הבסיסיים ביותר בכל מה שקשור ל-benchmark. יש עליו לא מעט ביקורת – הוא לא בודק ביצועי פרונט אנד, הוא לא מדמה ממש משתמשים ואפילו ה-concurrent שלו זה בסך הכל threads. התוצאות יהיו שונות ממכונה למכונה וכו'. אבל יש לו כמה יתרונות: הוא חינמי, פשוט לתפעול, קל לקריאה ושימוש נבון בו יכול לעזור מאוד.
