آپاچی جی‌متر چیست؟ معرفی JMeter برای تست بار و کارایی

Apache JMeter (آپاچی جی‌متر) ابزار متن‌بازی برای طراحی و اجرای آزمون‌های کارایی نرم‌افزار است. با این ابزار می‌توان درخواست‌های هم‌زمان ایجاد کرد و رفتار یک سامانه را در شرایط مختلف بار بررسی کرد.

برای مثال، می‌توانید سناریویی بسازید که تعداد مشخصی کاربر مجازی به یک API درخواست بفرستند و سپس زمان پاسخ، نرخ خطا و توان عملیاتی سامانه را بررسی کنید.

جی‌متر فقط برای وب‌سایت‌ها نیست. این ابزار از HTTP و HTTPS و همچنین فناوری‌هایی مانند JDBC، FTP، LDAP، JMS و TCP پشتیبانی می‌کند و به همین دلیل برای بررسی انواع سرویس‌ها و سامانه‌های تحت شبکه قابل استفاده است.

تفاوت آزمون کارایی، بار و فشار

Performance Testing (آزمون کارایی) عنوان کلی‌تری برای بررسی رفتار سامانه از نظر سرعت، ظرفیت و پایداری است.

Load Testing (آزمون بار) معمولا بررسی می‌کند سامانه زیر حجم کاری مورد انتظار یا هدف چگونه رفتار می‌کند.

Stress Testing (آزمون فشار) بار را از محدوده عادی فراتر می‌برد تا محدودیت ظرفیت، نحوه افت عملکرد یا رفتار سامانه هنگام نزدیک‌شدن به اشباع بررسی شود.

جی‌متر حالت جداگانه‌ای با نام «تست فشار» ندارد؛ نوع آزمون را الگوی باری که طراحی می‌کنید مشخص می‌کند.

سناریوی آزمون در JMeter چگونه ساخته می‌شود؟

هر سناریو در قالب Test Plan (طرح آزمون) ساخته می‌شود و از چند نوع عنصر تشکیل می‌شود.

Thread Group (گروه کاربران مجازی) مشخص می‌کند چند رشته یا کاربر شبیه‌سازی‌شده سناریو را اجرا کنند، آغاز آن‌ها با چه سرعتی انجام شود و سناریو چند بار تکرار شود.

Sampler (عنصر ارسال درخواست) عملیات اصلی را انجام می‌دهد؛ برای مثال، یک درخواست HTTP به API ارسال می‌کند یا یک پرس‌وجوی JDBC اجرا می‌کند.

Assertion (اعتبارسنجی پاسخ) بررسی می‌کند نتیجه فقط از نظر دریافت پاسخ موفق نباشد و محتوای مورد انتظار نیز برگردد.

Controller (کنترل‌کننده جریان) برای تکرار، شرط، ترتیب و مدیریت مسیر اجرای درخواست‌ها استفاده می‌شود.

Listener (گزارش‌گر نتیجه) نیز داده‌های آزمون را ثبت یا نمایش می‌دهد.

کاربران مجازی با کاربران واقعی یکسان نیستند

تعداد Threadها در جی‌متر را نباید مستقیماً برابر تعداد کاربران واقعی یک محصول در نظر گرفت.

نرخ واقعی درخواست به زمان پاسخ سامانه، مکث میان عملیات، ساختار سناریو، تعداد درخواست‌های هر کاربر و مدل بار بستگی دارد.

برای مثال، دو آزمون با ۵۰۰ کاربر مجازی می‌توانند نرخ درخواست کاملاً متفاوتی تولید کنند.

جی‌متر مرورگر نیست

جی‌متر در سطح پروتکل کار می‌کند و رفتار کامل مرورگر را شبیه‌سازی نمی‌کند.

در آزمون HTTP می‌تواند درخواست‌هایی مشابه مرورگر ارسال کند، اما صفحه را مانند Chrome یا Firefox رندر نمی‌کند و جاوااسکریپت موجود در HTML را اجرا نمی‌کند.

بنابراین اگر هدف شما اندازه‌گیری زمان رندر رابط کاربری، اجرای جاوااسکریپت یا معیارهای تجربه واقعی مرورگر است، باید از ابزارهای مناسب آزمون مرورگر یا پایش تجربه کاربر در کنار جی‌متر استفاده کنید.

شروع یک آزمون قابل اتکا

۱. ابتدا بار هدف را مشخص کنید.

پیش از ساخت سناریو مشخص کنید چه رفتاری را می‌خواهید بررسی کنید.

برای مثال:

• تعداد یا نرخ درخواست مورد انتظار

• مسیرهای اصلی کاربران

• مدت آزمون

• صدک زمان پاسخ

• نرخ خطای قابل قبول

• توان عملیاتی مورد انتظار

اگر هدف آزمون مشخص نباشد، اعداد خروجی به‌تنهایی اطلاعات زیادی درباره کیفیت سامانه نمی‌دهند.

۲. سناریو را ابتدا با بار کم بررسی کنید.

پیش از اجرای بار اصلی، سناریو را با یک یا چند کاربر اجرا کنید.

درستی نشانی‌ها، پارامترها، احراز هویت، نشست‌ها، توکن‌ها و داده‌های متغیر را بررسی کنید.

برای پاسخ‌های مهم نیز اعتبارسنجی قرار دهید تا پاسخ دارای خطا یا محتوای اشتباه به‌عنوان اجرای موفق ثبت نشود.

۳. داده‌های آزمون را پارامتردهی کنید.

استفاده از یک نام کاربری، شناسه یا ورودی ثابت برای همه کاربران می‌تواند رفتار غیرواقعی ایجاد کند.

با CSV Data Set Config می‌توانید داده‌هایی مانند نام کاربری، شناسه کالا یا پارامترهای دیگر را از فایل بخوانید و میان اجراها تغییر دهید.

برای داده‌هایی که در پاسخ یک درخواست ساخته می‌شوند، مانند توکن یا شناسه نشست، مقدار موردنیاز را از پاسخ استخراج و در درخواست بعدی استفاده کنید.

۴. بار اصلی را از خط فرمان اجرا کنید.

رابط گرافیکی برای ساخت، بررسی و رفع اشکال سناریو مناسب است.

برای آزمون بار اصلی، از حالت خط فرمان (CLI) استفاده کنید و گزارش‌گرهای سنگینی را که همه جزئیات درخواست‌ها را در حافظه نگه می‌دارند غیرفعال کنید.

این کار کمک می‌کند منابع ماشین تولیدکننده بار کمتر بر نتیجه آزمون اثر بگذارند.

۵. خود ماشین تولیدکننده بار را هم بررسی کنید.

اگر CPU، حافظه یا شبکه ماشینی که JMeter روی آن اجرا می‌شود به محدودیت برسد، ممکن است ابزار نتواند بار هدف را تولید کند.

در بارهای بزرگ‌تر می‌توان چند نمونه JMeter را روی چند ماشین اجرا کرد یا از اجرای توزیع‌شده استفاده کرد.

در اجرای توزیع‌شده باید توجه داشت که هر موتور راه‌دور طرح آزمون را اجرا می‌کند و مجموع بار حاصل از همه موتورها به سامانه هدف وارد می‌شود.

۶. شاخص‌های سرور را هم‌زمان پایش کنید.

خروجی جی‌متر فقط بخشی از تصویر است.

زمان پاسخ یا نرخ خطا نشان می‌دهد مشکلی رخ داده، اما لزوماً علت آن را مشخص نمی‌کند.

هم‌زمان معیارهایی مانند موارد زیر را بررسی کنید:

• مصرف پردازنده

• حافظه

• اتصال‌های پایگاه داده

• صف‌ها

• ورودی و خروجی دیسک

• شبکه

• خطاهای برنامه

برای این بخش می‌توان از سامانه‌های پایش مانند Prometheus و Grafana استفاده کرد.

۷. نتیجه را با خط مبنا مقایسه کنید.

یک اجرای قابل تکرار را به‌عنوان Baseline (خط مبنا) نگه دارید.

پس از تغییر کد، زیرساخت یا پایگاه داده، آزمون را با شرایط تا حد ممکن مشابه اجرا کنید و نتیجه را با خط مبنا مقایسه کنید.

نسخه نرم‌افزار، داده آزمون، تنظیمات محیط و الگوی بار را نیز ثبت کنید تا مقایسه‌ها معنی‌دار باشند.

چه شاخص‌هایی را در نتیجه بررسی کنیم؟

میانگین زمان پاسخ به‌تنهایی برای تحلیل نتیجه کافی نیست.

بهتر است چند معیار را کنار هم ببینید.

صدک زمان پاسخ:برای مثال، صدک ۹۵ نشان می‌دهد ۹۵ درصد نمونه‌ها حداکثر تا آن زمان پاسخ گرفته‌اند. این معیار می‌تواند رفتار بخش کندتر درخواست‌ها را بهتر از میانگین نشان دهد.

نرخ خطا:درصد درخواست‌هایی که به خطا، زمان پایان‌یافته یا اعتبارسنجی ناموفق رسیده‌اند.

توان عملیاتی:تعداد عملیات یا درخواست‌هایی که در یک بازه زمانی پردازش شده‌اند.

تعداد کاربران یا رشته‌های فعال:برای بررسی اینکه بار موردنظر واقعا در طول آزمون فعال بوده است.

این معیارها باید در کنار داده‌های سرور و هدف تجاری آزمون تفسیر شوند.

انتخاب JMeter یا ابزار دیگر

چه زمانی JMeter مناسب است؟

جی‌متر برای تیمی مناسب است که می‌خواهد سناریو را با رابط گرافیکی بسازد و رفع اشکال کند، سپس همان طرح آزمون را از خط فرمان اجرا کند.

پشتیبانی از پروتکل‌های مختلف، پارامتردهی داده، کنترل جریان، استخراج داده از پاسخ و اجرای توزیع‌شده نیز آن را برای سناریوهای متنوع مناسب می‌کند.

چه زمانی k6 یا Gatling را بررسی کنیم؟

اگر تیم ترجیح می‌دهد آزمون‌های بار مانند کد نوشته شوند، در Git نگهداری شوند و بخشی از فرایند توسعه و بازبینی کد باشند، ابزارهایی مانند k6 و Gatling نیز گزینه‌های مناسبی هستند.

انتخاب میان آن‌ها بیشتر به زبان مورد استفاده تیم، مدل بار، زیرساخت اجرا و نحوه نگهداری سناریوها بستگی دارد.

جایگاه Postman چیست؟

Postman علاوه بر آزمون عملکردی API، امکان اجرای آزمون‌های کارایی و شبیه‌سازی کاربران مجازی را نیز دارد.

اگر سناریوهای شما حول مجموعه‌های API و محیط Postman ساخته شده‌اند، قابلیت‌های آزمون کارایی آن نیز ارزش بررسی دارند.

جی‌متر همچنان برای سناریوهایی که به پروتکل‌های متنوع‌تر یا ساختار گسترده Test Plan نیاز دارند گزینه متفاوتی است.

پیش‌نیاز اجرای JMeter

جی‌متر روی Java اجرا می‌شود و باید نسخه Java سازگار با نسخه JMeter نصب‌شده باشد.

بهتر است نسخه Java و JMeter را پیش از اجرای آزمون‌های مهم با مستندات همان نسخه تطبیق دهید.