آموزش Load Testing – راهنمای سریع Apache Bench

امروز میخوام یک آموزش سریع و کمی کامل از Apache Bench براتون بزارم.

ApacheBench یه ابزار قدیمی، دم دستی و البته خیلی کار راه انداز برای اجرای load testing و stress testing هست.

با طراحی درست تست و تحلیل خروجی اون میتونید تخمین مناسبی از میزان ظرفیتی که سیستم میتونه تحمل کنه به دست بیارید.

در load testing با شبیه سازی میزان ظرفیتی که از سیستم انتظار داریم از اون کار میکشیم تا ببینیم سیستم جواب میده یا نه.

stress testing هدفش ایجاد اختلال در سیستم به وسیله ایجاد حجم غیر عادی درخواست هست و بعد هم مشاهده اینکه سیستم چجوری غیر فعال میشه و چجوری خودش رو بازیابی میکنه.

موقع طراحی تست یادتون باشه که تست API با وب سایت فرق داره. چرا؟

تو API وقتی کاربر میخواید عملیاتی انجام بده مثل گرفتن لیست آخرین اخبار فقط باید یک درخواست بزنه درحالیکه وقتی کاربر یک سایت رو باز میکنه هم صفحه اصلی سایت رو میگیره و هم بقیه فایلها رو که همه اینها درخواست هست برای مثال اگه به قسمت  Developer Tools -> Network مرورگرتون برید و این سایت رو باز کنید در گوشه پایین چپ تعداد کل درخواست ها رو زده ۳۵ بنابراین هر کاربر که سایت رو باز میکنه ۳۵ تا درخواست میزنه حالا چند تاشون همزمانه؟

تعداد اتصالهای همزمانی که مرورگر به سایت برقرار میکنه به خود مرورگر بستگی داره اما به طور متوسط مرورگر برای هر هاست به طور همزمان ۶ تا اتصال به سرور میزنه تا فایلها رو دانلود کنه.

بنابراین برای تست ۱۰۰ کاربر با فرض اینکه در هر بار لود سایت ۳۵ درخواست به سرور فرستاده میشه تعداد کل درخواست ها میشه ۳۵۰۰ و تعداد درخواست های همزمان هم میشه 600 =  ۱۰۰ * ۶ که در ادامه توضیح میدم چجوری این حجم ورودی رو شبیه سازی کنید.

در تمام مقاله منظور از سیستم، سرور API یا وب سایتی هست که تست روی اون انجام میشه.

دستور زیر رو برای شروع در نظر بگیرید

دستور بالا به مدت یک دقیقه یه صورت ۱۰۰ تا 100 تا درخواست به htp://localhost میفرسته

  • متد پیش فرض GET هست
  • t- مدت زمان مجازی هست که کل تست میتونه طول بکشه
  • c- تعداد درخواست های همزمان که تو مدت زمان بالا باید ارسال بشه
  • k- یعنی از اتصال keepalive استفاده کنه البته این بستگی داره که سیستم از این قابلیت پشتیبانی کنه یا نه
  • r- اگه به خطا خورد تست قطع نشه و ادامه پیدا کنه
  • v- تعداد سطح نمایش لوگ که اگه ۱ بزارید فقط نتایج رو نشون میده و اگه ۲ بزارید هم درخواست http و هم جوابی که گرفته رو نشون میده

اگه ab خطا داد انتهای ادرس / بزارید.

اگه بخواید هدر http هم بفرستید از سوییچ H- باید استفاده کنید به طور مثال ‘H ‘User-Agent: XXX-

اگه اندازه جواب از سیستم متغیر هست باید l- هم اضافه کنید در غیر اینصورت ab اندازه خروجی اول رو نگه میداره و اگه اندازه جواب های بعدی با این متفاوت باشه اون درخواست ها رو خطا حساب میکنه و تو گزارش تحت عنوان Failed requests قرارمیده.

بیشترین تعداد درخواست همزمان مجاز تو ab حداکثر میتونه 20 هزار تا باشه، باید بدونید که ارسال این مقدار درخواست همزمان هزینه زیادی نداره در واقع ارسال درخواست خیلی هزینه نداره بلکه سرو کردن این مقدار خیلی هزینه داره که باعث غیر فعال شدن سیستم میشه

دستور زیر ۶۰۰۰ درخواست رو در دسته های ۱۰۰ تایی (یعنی به طور همزمان ۱۰۰ درخواست) ارسال میکنه

n- تعداد کل درخواست هایی که باید فرستاده بشه رو مشخص میکنه

برای تست وب سایتی که بالاتر بهش اشاره شد اگه بخوایم ۳۵۰۰ درخواست با همزمانی ۶۰۰ ارسال کنیم

برای انجام تستها میتونید تعداد درخواست ها رو مشخص کنید و یا اینکه یک زمان بدید این سلیقه ای هستش و البته کمی هم به نوع سیستم بستگی داره.

وقتی سوییچ t- رو مشخص میکنید ab تعداد مجاز کل درخواستها رو 50 هزار تا میزاه برای مثال اگه سیستم خیلی سریع باشه و این مقدار درخواست رو تو ۱۰ ثانیه جواب بده همونجا تست متوقف میشه برای حل این مشکل باید مقدار کل درخواستها رو خیلی زیاد بزارید

اینجوری تست تا ۶۰ ثانیه ادامه پیدا میکنه

سوییچ n- حتما باید بعد از t- بیاد در غیر اینصورت مقدار n برابر ۵۰۰۰۰ قرار داده میشه تو راهنمای ab این مقدار رو میتونید بینید.

یک مثال از ارسال اطلاعات json با متد POST

سوییچ T- هدر Content-Type رو تنظیم میکنه

درخواست POST میتونه حاوی بدنه اطلاعات باشه ولی اگه درخواست شما حاوی این اطلاعات نیست باید سوییج p- رو حذف کنید و سوییچ m POST- رو اضافه کنید.

data.json اطلاعاتی هست که باید فرستاده بشه

و اگه بخواید یک فرم بفرستید

که فایل data.form محتویاتی با ساختار زیر باید داشته باشه

برای ارسال اطلاعات با متد PUT باید از سوییچ u- استفاده کنید

درخواست PUT میتونه حاوی بدنه اطلاعات باشه ولی اگه درخواست شما حاوی این اطلاعات نیست باید سوییج u- رو حذف کنید و سوییچ m PUT- رو اضافه کنید.

برای استفاده از متدهای HEAD ,PATCH یا DELETE باید اسم متد رو برای سوییچ m- تنظیم کنید.

مثال ارسال درخواست PATCH

وقتی از متد POST یا PUT برای ارسال json یا form استفاده میکنید لازم نیست سوییج m- رو اضافه کنید چون خود ab به وسیله سوییچ p- یا u- (که باید اضافه کنید) نوع متدی که باید استفاده کنه رو متوجه میشه.

برای فهمیدن تفاوت متدهای GET, HEAD, PUT این نوشته رو بخونید

چجوری گزارش رو تحلیل کنیم؟

من ۷ تا تست روی سیستم API شرکتمون اجرا کردم که نتایجش به اینصورت هست

تست یک – ۱ درخواست همزمان

تست دو – ۱۰ درخواست همزمان

تست سه – ۲۰ خواست همزمان

تست چهار – ۵۰ درخواست همزمان

تست پنج – ۷۵ درخواست همزمان

تست شش – ۱۰۰ درخواست همزمان

تست هفت – ۱۰۰۰ درخواست همزمان

توضیح فیلدها

Time taken for tests: مدت زمانی که کل تست طول کشیده

Requests per second: تعداد درخواست ها در یک ثانیه

Failed requests: درخواست هایی که به خطا خوردن مثلا سیستم نتوسته جواب بده یا…

Non-2xx responses: جواب هایی که کد http اونها با 2 شروع نشدن که به احتمال زیاد خطا هستند.

(Time per request(mean: مشخص میکنه هر بار که تعداد N درخواست همزمان زدیم کل اون درخواستهای همرمان هر بار به طور متوسط چقدر طول کشیده برای مثال اگه تعداد درخواستهای همزمانمون ۱۰۰ باشه این مقدار نشون میده که به طور متوسط این ۱۰۰ درخواست چقدر طول کشیده حالا اگه این رو تقسیم بر تعداد درخواست های همزمان کنیم مقدار قبلی یعنی Time per request: X [ms] (mean, across all concurrent requests)  به دست میاد

(Time per request(mean, across all concurrent requests: مشخص میکنه که به طور متوسط هر درخواست چقدر طول کشیده

Connection Times: مدت زمان ارسال و دریافت اطلاعات برای هر دسته درخواست با توضیح زیر

  • Connect: زمانی که طول میکشه درخواست ارسال بشه که به سرعت شبکه بستگی داره
  • Processing: مدت زمانی که طول میشکه سیستم جواب درخواست رو آماده کنه
  • Waiting: مدت زمانی که طول میشکه تا جواب دریافت بشه که به سرعت شبکه بستگی داره
  • Total: مجموع Connect و Processing

چون Connect و  Waiting به شبکه بستگی داره پس نباید در تحلیل گزارش تاثیرش بدیم فقط فیلد Processing رو باید در نظر بگیریم.

خلاصه ای از همه تستها که فقط فیلدهایی که برامون مهم هستند رو نشون میده

تست یک – 1 درخواست همزمان

  • Time taken for tests: 28.454 seconds
  • Requests per second: 35.14 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 0
  • Time per request (mean, across all concurrent requests): 28.454 [ms]
  • Connection Times (Processing (median)): 25

 

تست دو – 10 درخواست همزمان

  • Time taken for tests: 24.976 seconds
  • Requests per second: 40.04 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 0
  • Time per request (mean, across all concurrent requests): 24.976 [ms]
  • Connection Times (Processing (median)): 232

تست سه – 20 درخواست همزمان

  • Time taken for tests: 19.804 seconds
  • Requests per second: 50.50 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 0
  • Time per request (mean, across all concurrent requests): 19.804 [ms]
  • Connection Times (Processing (median)): 363

تست چهار – 50 درخواست هزمان

  • Time taken for tests: 19.181 seconds
  • Requests per second: 52.13 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 0
  • Time per request (mean, across all concurrent requests): 19.181 [ms]
  • Connection Times (Processing (median)): 864

تست پنچ – 75 درخواست همزمان

  • Time taken for tests: 19.248 seconds
  • Requests per second: 51.95 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 0
  • Time per request (mean, across all concurrent requests): 19.248 [ms]
  • Connection Times (Processing (median)): 1311

تست شش – 100 درخواست همزمان

  • Time taken for tests: 18.327 seconds
  • Requests per second: 54.56 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 20
  • Time per request (mean, across all concurrent requests): 18.327 [ms]
  • Connection Times (Processing (median)): 1718

تست هفت – 1000 درخواست همزمان

  • Time taken for tests: 17.648 seconds
  • Requests per second: 56.66 [#/sec] (mean)
  • Failed requests: 0
  • Non-2xx responses: 36
  • Time per request (mean, across all concurrent requests): 17.648 [ms]
  • Connection Times (Processing (median)): 9280

با مقایسه نتایج متوجه میشیم که تست سه با تعداد درخواست همزمان 20 بهترین نتایج رو داره. چرا؟

  • چون مقدار Time taken for tests و Requests per second این تست نسبت به تست های بعدیش بهبود قابل توجه و چشم گیری نداشته
  • چون مقدار Non-2xx responses صفر هست
  • چون مقدار  ((Connection Times (Processing(median  نسبت به تست های بعدش مقدار  قابل قبول تری هست.

پس با اطمینان میگیم که سیستم ما برای 20 تا کمتر از حدود 100 درخواست همزمان (باید بین 75 تا 100 چند تا تست دیگه انجام بشه تا مقدار دقیقش به دست بیاد) به صورت عادی و بدون مشکل کار خواهد کرد ولی برای 100 درخواست همزمان و بیشتر از اون ممکن هست بعضی از درخواست ها به خطا بخوره.

برای اینکه از خروجی یک نمودار گرافیکی داشته باشم اول باید در تست با سوییچ x- یک ورودی به عنوان اسم فایل بدیم بعد وارد gnuplot شیم و دستورهای زیر رو وارد کنیم

برای اینکه خروجی csv از گزارش داشته باشید باید از سوییچ e- استفاده کنید به صورت زیر

منابع
۱

جستجو در کل مطالب سایت

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *