در محیط فنی، ممکن است بگوییم یک کوئری از ۱۰ میلی ثانیه به ۳ میلی ثانیه رسیده است، اما برای مدیران یا تیم های غیر فنی این عددها خیلی معنا دار نیستند. چیزی که برای تصمیم گیری اهمیت دارد، اثر کلی روی سیستم است؛ مثلاً کاهش بار سرور، افزایش توان پردازش هم زمان، یا بهبود زمان پاسخ در مقیاس بالا.
چرا صرفاً دیدن Time و IO کافی نیست؟
وقتی یک کوئری را در SSMS اجرا می کنیم، معمولاً با ابزارهایی مثل:
- Execution Plan
- SET STATISTICS IO ON
- SET STATISTICS TIME ON می توانیم بفهمیم آیا کوئری نیاز به بهینه سازی دارد یا نه. اما این داده ها فقط در سطح یک اجرا مفیدند. اگر بخواهیم به کسب وکار نشان دهیم که یک تغییر چقدر ارزش دارد، باید بتوانیم رفتار کوئری، در اجرای تکراری و هم زمان را هم اندازه بگیریم.
SQLQueryStress چیست؟
SQLQueryStress یک ابزار رایگان و ساده برای شبیه سازی اجرای هم زمان کوئری ها یا stored procedureها توسط چند کاربر مجازی است.
با این ابزار می توانیم مشخص کنیم:
- کوئری چند بار اجرا شود
- چند thread یا کاربر مجازی هم زمان آن را اجرا کنند
- رفتار کوئری تحت فشار واقعی تر چگونه است
ساخت یک دیتاست آزمایشی:
برای نمایش قابلیت ابزار، یک دیتابیس نمونه ساخته می شود که سه جدول اصلی دارد.
در این سناریو، جدول SalesOrder حدود یک میلیون رکورد دارد تا تست ها واقع گرایانه تر باشند.
دو جدول مهم عبارت اند از:
- SalesPerson برای اطلاعات فروشنده
- SalesOrder برای سفارش های فروش
در این ساختار:
- هر فروشنده یک شناسه یکتا دارد
- هر سفارش به یک فروشنده مرتبط است
- تاریخ ثبت و مقدار فروش هم ذخیره می شود
هدف از این دیتاست این است که بتوانیم یک کوئری پرتکرار را در شرایط واقعی تر آزمایش کنیم.
نمونه کوئری مورد بررسی:
یک کوئری نمونه که "مجموع فروش دو شماره پرسنل مشخص را محاسبه می کند" به صورت مداوم توسط برنامه اجرا می شود. شماره پرسنلی 000127 و 000508
کوئری به جدول سفارش ها و جدول فروشندگان join می زند و در نهایت مجموع فروش را بر اساس شماره کارمند گروه بندی می کند.
وقتی Execution Plan این کوئری بررسی می شود، مشخص است که با افزودن یک ایندکس مناسب، عملکرد آن به طور محسوسی بهتر خواهد شد. اما مشکل اینجاست که اگر بخواهیم این بهبود را فقط با یک اجرای منفرد توضیح دهیم، ارزش تجاری آن به خوبی دیده نمی شود.
چرا SQLQueryStress مفید است؟
فرض کنید یک کوئری بدون ایندکس در هر بار اجرا فقط چند میلی ثانیه کندتر باشد. این اختلاف ممکن است کوچک به نظر برسد، اما اگر:
- همان کوئری هزاران بار در روز اجرا شود
- چندین کاربر هم زمان از آن استفاده کنند
- سیستم تحت بار واقعی باشد
آن چند میلی ثانیه می تواند به فشار قابل توجه روی CPU، IO و latency تبدیل شود.
SQLQueryStress کمک می کند این اختلاف را در مقیاس بزرگ تر ببینیم.
به جای اینکه بگوییم «کوئری ۷ میلی ثانیه سریع تر شد»، می توانیم بگوییم:
- این تغییر در ۱۰٬۰۰۰ اجرای هم زمان یا تکراری چه اثری داشته
- بار سرور چقدر کاهش یافته
- زمان پاسخ در شرایط واقعی چه تفاوتی کرده
این نوع گزارش برای تصمیم گیرندگان بسیار قانع کننده تر است.
نحوه استفاده از SQLQueryStress:
1. روی بخش Database کلیک کنید
2. اطلاعات اتصال به SQL Server را وارد کنید
3. اگر لازم است دیتابیس پیش فرض را مشخص کنید
نکته مهم: این تست ها باید فقط در محیط آزمایشی انجام شوند. چون اجرای هم زمان و پرتکرار کوئری ها می تواند بار زیادی به سرور وارد کند.
تنظیمات اصلی نرم افزار:
در سمت چپ محیط SQLQueryStress، بخشی برای وارد کردن کوئری تست وجود دارد.
بعد از وارد کردن Query، دو تنظیم مهم باید مشخص شوند:
1) Number of Iterations:
این گزینه مشخص می کند هر thread چند بار کوئری را اجرا کند. اگر مقدار آن 1 باشد، هر thread فقط یک بار اجرا خواهد کرد.
2) Threads / Virtual Users:
این گزینه تعداد کاربرهای مجازی یا threadهای هم زمان را تعیین می کند. هرچه این عدد بیشتر باشد، فشار بیشتری به SQL Server وارد می شود و تصویر دقیق تری از رفتار سیستم تحت بار به دست می آید.
این ابزار در عمل چه کمکی می کند؟
SQLQueryStress به شما اجازه می دهد قبل و بعد از تغییرات، عملکرد را مقایسه کنید. مثلاً:
- قبل از ایجاد ایندکس
- بعد از ایجاد ایندکس
- قبل از بازنویسی کوئری
- بعد از بازنویسی کوئری
در این حالت می توان معیارهای زیر را بررسی کرد:
- زمان اجرای متوسط
- تعداد اجرای موفق
- مصرف CPU
- IO
- پایداری عملکرد در اجرای هم زمان
سید حامد واحدی
2 مرداد 1405