تست بار: پیدا کردن نقطهٔ شکست پیش از مشتری
سامانهای که با ده کاربر آزمایشی بینقص کار میکند، دربارهٔ رفتارش با هزار کاربر همزمان هیچ چیزی نمیگوید. نه چیز خوبی، نه چیز بدی. صرفاً آزمایشی است که سؤال دیگری را جواب داده.
و مسئله این است که نقطهٔ شکست یک شیب نیست، یک لبه است. سامانه تا یک حدی کند میشود و بعد از آن حد، ناگهان صف تشکیل میشود، اتصالها تمام میشوند، درخواستها تایماوت میخورند و بازیابی خودبهخودی هم اتفاق نمیافتد.
پیدا کردن آن لبه، همهٔ کاری است که تست بار انجام میدهد.
چهار تست که یکی نیستند
اسمها را تیمها جابهجا به کار میبرند، ولی سؤالهایشان کاملاً متفاوت است:
تست بار. «با بار مورد انتظار، آیا به بودجهٔ کارایی میرسیم؟» — تأیید، نه اکتشاف.
تست فشار. «کجا میشکند؟» بار را بالا میبریم تا سامانه از پا دربیاید. هدف پیدا کردن سقف است، نه گذراندن تست.
تست جهش. «اگر بار در سی ثانیه ده برابر شود چه میشود؟» این سناریوی واقعی کمپین تخفیف، پیامک انبوه، و اعلان همگانی است — و سامانههایی که تست بار تدریجی را قبول میشوند، اغلب اینجا رد میشوند.
تست پایداری. «شش ساعت زیر بار متوسط چه میشود؟» نشت حافظه، پر شدن دیسک از لاگ، و اتصالهایی که بسته نمیشوند، فقط اینجا خودشان را نشان میدهند.
تیمی که فقط اولی را انجام میدهد، سه سؤال بیجواب دارد. و در عمل، دومی و سومی هستند که در راهاندازی واقعی بهکار میآیند.
سناریو، جایی که بیشتر تستها بیفایده میشوند
بزرگترین اشتباه تست بار این است: هزار درخواست به صفحهٔ اول زده میشود، سامانه جواب میدهد، و تیم نتیجه میگیرد که آماده است.
صفحهٔ اول معمولاً کش شده و ارزان است. بار واقعی جای دیگری است.
سناریوی معتبر سه ویژگی دارد:
مسیر کامل کاربر است، نه یک نقطه. ورود، جستوجو، مشاهدهٔ محصول، افزودن به سبد، ثبت سفارش. ترکیب واقعی اینها را از لاگ سامانهٔ فعلی دربیاورید، نه از حدس. تقریباً همیشه توزیع واقعی با چیزی که تیم فرض میکند فرق دارد.
دادهاش متنوع است. هزار کاربر مجازی که همه یک محصول را جستوجو میکنند، کش را گرم میکنند و چیزی را تست نمیکنند. جستوجو باید عبارتهای متفاوت داشته باشد، سبد باید محصولهای متفاوت. اینجاست که دادهٔ تست از یک کار جانبی به پیشنیاز تبدیل میشود.
حجم پایگاه داده واقعی است. این مهمترین بند است و بیشترین بیتوجهی را میبیند. تست بار روی پایگاه دادهای با پنج هزار رکورد، وقتی تولید دو میلیون رکورد دارد، عملاً هیچ چیزی را تست نمیکند — چون آنچه در تولید کند است، پرسوجوی بدون ایندکس است که با پنج هزار رکورد سریع اجرا میشود.
جزئیات این سمت مسئله در کارایی پایگاه داده آمده.
محیط: چه چیزی باید شبیه تولید باشد
تست بار روی لپتاپ توسعهدهنده عددی میدهد که فقط دربارهٔ آن لپتاپ است.
ترتیب اهمیت، از تجربه:
۱. حجم و توزیع داده — بیشترین اثر، کمترین هزینه برای شبیهسازی. ۲. پیکربندی پایگاه داده — تعداد اتصال مجاز، حافظهٔ اختصاصیافته. ۳. تعداد نمونههای سرویس — یک نمونه در آزمون، چهار نمونه در تولید، عدد بیربطی میدهد. ۴. سختافزار — معمولاً کماثرتر از سه مورد بالاست.
اگر محیط تولید را نمیشود بازسازی کرد، نسبت را ثبت کنید: «محیط آزمون یک سوم تولید است.» بعد نتیجه را با همان نسبت بخوانید و در گزارش بنویسید. عددی که شرایطش ثبت نشده، عددی است که سال بعد کسی نمیداند یعنی چه — همان چیزی که محیطها و پیکربندی به آن میپردازد.
خواندن نتیجه
سه عدد، به همین ترتیب:
درصدکهای زمان پاسخ، نه میانگین. ۵۰، ۹۵، ۹۹. اگر ۵۰ خوب است و ۹۹ فاجعه، شما مسئلهٔ صف دارید نه مسئلهٔ سرعت.
نرخ خطا. سامانهای که سریع جواب میدهد ولی سه درصد درخواستها را رد میکند، تست را رد شده. این را تیمها زیاد از قلم میاندازند چون ابزار زمان پاسخ را برجسته نشان میدهد.
نقطهٔ عطف. آن نموداری که تا جایی مسطح است و بعد عمودی میشود. عدد قبل از عطف، ظرفیت واقعی شماست — نه عددی که در آن سامانه هنوز جواب میدهد.
و بعد سؤالی که تست را به کار تبدیل میکند: گلوگاه کجا بود؟ بدون پایش در حین تست، جواب حدس است. با پایش، جواب معمولاً یکی از این چهارتاست: پایگاه داده، تعداد اتصال، فراخوانی سرویس بیرونی، یا قفلی در کد.
کِی انجام دهیم
نه یک بار. سه لحظه:
بعد از تثبیت معماری، پیش از ساخت بیشتر. روی یک نمونهٔ اسکلتی از سنگینترین مسیر. اگر معماری قرار است کم بیاورد، اینجا ارزانترین جای فهمیدنش است.
در خط لوله، سبک و مکرر. یک سناریوی کوچک که در هر بیلد اجرا میشود و اگر زمان پاسخ بیش از حدی بدتر شد هشدار میدهد. هدفش پیدا کردن سقف نیست؛ پیدا کردن تغییری که کند کرده است، در روزی که وارد شده. جایگاهش در خط لولهٔ قابل اعتماد.
پیش از رویداد شناختهشده. کمپین، شروع ثبتنام، فصل اوج. اینجا تست جهش مهمتر از تست بار است.
اشتباههایی که بارها دیدهایم
تست از داخل همان شبکه. تأخیر شبکه و لایهٔ توزیع محتوا حذف میشوند و عدد خوشبینانه میشود.
نادیده گرفتن کش گرم. اجرای اول کند است و بقیه سریع. اگر در تولید کش هر شب پاک میشود، عدد اجرای اول عدد واقعی شماست.
تست کردن سامانه بدون سرویسهای بیرونی. درگاه پرداخت و سرویس پیامک زیر بار هم محدودیت نرخ دارند. تست بار بدون آنها، سناریوی خوشبینانهای است که هیچ کاربری تجربهاش نمیکند. اگر نمیشود واقعیشان کرد، دستکم تأخیرشان را شبیهسازی کنید.
رها کردن نتیجه. گزارشی که به آیتم بکلاگ تبدیل نشود، فایل است. هر گلوگاه کشفشده باید یا رفع شود یا با تاریخ و محرک بازنگری پذیرفته شود.