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