با میانگین صدک ۹۵، سرعت دستیار را نسنجید

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

حتی اگر محاسبه درست باشد، تغییر ترکیب درخواست‌ها ممکن است بهبود ظاهری بسازد. مثال فرضی این مطلب نشان می‌دهد عدد کل از هزار به ۱۵۰ میلی‌ثانیه می‌رسد، در حالی که هر دو گروه درخواست کندتر شده‌اند. این آزمایش محصول ژرف نیست؛ تمرینی برای خواندن درست گزارش سرعت است.

صدک، خلاصه‌ای است که بخشی از اطلاعات را کنار می‌گذارد

زمان درخواست‌ها را از کوتاه‌ترین تا بلندترین مرتب کنید. صدک ۹۵، یا p95، به بخش بالایی این ترتیب نگاه می‌کند؛ برخلاف میانگین، جمع زمان‌ها تقسیم بر تعداد نیست. در مثال‌های این متن، جایگاه را با گرد کردن 0.95 × N به عدد صحیح بالاتر انتخاب می‌کنیم و مقدار همان مشاهده را برمی‌داریم.

این قرارداد را صریح نوشته‌ایم، چون روش محاسبه صدک در همه ابزارها یکسان نیست. راهنمای صدک‌های NIST چند روش رایج برآورد و درون‌یابی را توضیح می‌دهد. اختلاف روش‌ها، به‌ویژه در نمونه کوچک، اهمیت دارد. هنگام مقایسه دو گزارش، نام شاخص به‌تنهایی کافی نیست؛ روش و تعداد مشاهده هم باید معلوم باشد.

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

دو سرور، سه عدد و فقط یک صدک کل

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

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

در مجموعه ۱۱۰تایی، جایگاه صدک ۹۵ برابر ۱۰۵ است. صد مقدار اول صد میلی‌ثانیه‌اند و ده مقدار بعدی هزار؛ پس مشاهده ۱۰۵ام هزار میلی‌ثانیه است. هیچ‌کدام از دو میانگین، پاسخ درست را نداده‌اند.

مستندات هیستوگرام در Prometheus همین محدودیت را برای تجمیع صدک‌های ازپیش‌محاسبه‌شده توضیح می‌دهد. راه عملی، نگه‌داشتن مشاهده‌ها یا نمایش تجمیع‌پذیر توزیع آن‌هاست؛ نه ساختن میانگین زیباتری از خلاصه‌هایی که اطلاعات لازم را ندارند. همین مشکل درباره میانگین p95 پنج دقیقه‌های یک روز هم وجود دارد.

ترکیب تازه ترافیک، کندی هر دو گروه را پنهان می‌کند

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

در بازه دوم، مشاهده ۹۵۰ام داخل گروه کوتاه قرار می‌گیرد. عدد کل به‌درستی ۱۵۰ است؛ محاسبه خراب نیست. نتیجه‌گیری «نسخه تازه سریع‌تر شده» خراب است، چون گروه کوتاه از صد به ۱۵۰ و گروه طولانی از هزار به ۱۲۰۰ رسیده است.

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

گروه‌ها را پیش از دیدن نتیجه تعریف کنید: نوع کار، اندازه تقریبی ورودی یا مسیر ابزار. طول پاسخ تولیدشده را با احتیاط به کار ببرید؛ شاید خودِ نسخه جدید پاسخ‌ها را کوتاه کرده باشد. ثابت کردن این متغیر پس از اجرا ممکن است بخشی از اثر واقعی تغییر را از مقایسه حذف کند. مقایسه کار یکسان و گزارش طول واقعی خروجی، دو شاهد مکمل‌اند.

زمان‌سنج از کجا شروع می‌شود و کجا می‌ایستد؟

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

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

اگر وعده شما زمان انتظار کاربر است، اندازه‌گیری فقط داخل سرور کافی نیست؛ مسیر شبکه و نمایش را جدا بسنجید یا ادعا را به همان مرز سرور محدود کنید. راهنمای مهندسی تأخیر استنتاج اجزای این مسیر و انتخاب نقطه بهینه‌سازی را شرح می‌دهد. مسئله این مطلب یک قدم قبل‌تر است: آیا دو عدد اصلاً یک چیز را اندازه گرفته‌اند؟

تلاش دوباره را نیز روشن کنید. سه فراخوانی مدل برای یک پاسخ، سه تجربه کاربر نیست. زمان هر تلاش برای عیب‌یابی مفید است، ولی شاخص کاربر باید انتظار کل همان درخواست را منعکس کند. صدک مرحله‌ها را هم با هم جمع نکنید و نام حاصل را صدک سرتاسری نگذارید؛ کندترین مراحل الزاماً در همان درخواست‌ها رخ نمی‌دهند.

داده‌ای جمع کنید که تجمیع آن معنا داشته باشد

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

مدل داده شاخص‌ها در OpenTelemetry برای هیستوگرام، تعداد، بازه زمانی، مرز سبدها و نحوه انباشت را مشخص می‌کند. شمارش افزایشیِ هر دوره با شمارش انباشته از آغاز یکی نیست. مسیر جمع‌آوری باید این تفاوت و بازنشانی شمارنده را درست تبدیل کند؛ جمع کردن نسخه‌های پیاپی شمارش انباشته، درخواست‌ها را چندبار می‌شمارد.

پیشنهاد عملی ما ثبت یک قرارداد کوچک کنار شاخص است: واحد زمان، رویداد شروع و پایان، گروه درخواست، وضعیت نتیجه، بازه گزارش و نسخه تنظیمات اندازه‌گیری. برچسب‌ها محدود و ازپیش‌تعریف‌شده باشند. متن پرسش یا شناسه مشتری را برای تفکیک بی‌پایان وارد برچسب شاخص نکنید؛ هم هزینه می‌سازد و هم داده حساس را پخش می‌کند.

برای مرز پذیرش حساس، وضوح هیستوگرام مهم است. اگر حد مجاز دو ثانیه باشد و یک سبد از یک تا پنج ثانیه را بپوشاند، از شمارش آن سبد نمی‌فهمیم چند درخواست زیر دو ثانیه بوده. دقت نمایشیِ سه رقم اعشار، داده ازدست‌رفته را جبران نمی‌کند. سبدی با مرز مناسب یا شمارنده مستقیمِ تکمیل به‌موقع، تصمیم را روشن‌تر می‌کند.

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

خطاهای سریع را به حساب پاسخ‌های سریع نگذارید

ممکن است نسخه تازه کارهای دشوار را زودتر رد کند و p95 کل پایین بیاید. این الزاماً بهبود نیست. فصل پایش Google SRE بر جدا کردن تأخیر درخواست‌های موفق و ناموفق تأکید می‌کند؛ خطای سریع می‌تواند خواندن عدد کل را گمراه کند. حذف کامل خطاها از گزارش نیز تجربه واقعی را پنهان می‌کند.

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

برای تصمیم عملی، یک نسبت مکمل تعریف کنید: تعداد پاسخ‌های معتبرِ کامل‌شده تا مهلت مقرر، تقسیم بر همه درخواست‌های واجد شرایط. تعریف واجد شرایط را پیشاپیش تثبیت کنید. برای گروهی که بر اساس زمان ورود تشکیل شده، تا رسیدن مهلت اعضا صبر کنید یا موارد هنوز باز را جدا نشان دهید؛ مقایسه گروه کامل‌شده با گروه نیمه‌تمام منصفانه نیست.

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

آزمون بار نباید با کند شدن سرویس، خودبه‌خود آسان‌تر شود

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

مدل بسته همیشه اشتباه نیست؛ برای کاربری که واقعاً تا پاسخ صبر می‌کند مناسب است. اما اگر قرار است بار ورودی مستقل را بسنجید، گزارش تعداد کاربران مجازی به‌تنهایی کافی نیست. مشخص کنید چه نرخ ورودی‌ای برنامه‌ریزی شد، چه تعداد واقعاً ارسال شد و چه تعداد کامل شد. ناتوانی ابزار آزمون در تولید بار موردنظر را به حساب تحمل سرویس نگذارید.

شرایط حافظه نهان، گرم بودن مدل، اندازه ورودی و کیفیت پاسخ را همراه نتیجه نگه دارید. پاسخ کوتاه‌ترِ ناقص احتمالاً زودتر تمام می‌شود؛ این دلیل پذیرش آن نیست. حد قابل قبول کیفیت باید کنار شرط سرعت باقی بماند. هیچ‌یک از اعداد فرضی این مقاله نتیجه چنین آزمونی نیست.

چه گزارشی برای تصمیم انتشار کافی است؟

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

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

برای فهم علت یک کندی، مسیر همان درخواست را دنبال کنید؛ راهنمای مشاهده‌پذیری عامل به این تشخیص کمک می‌کند. چند ردگیری منتخب، جای شمارش نماینده کل ترافیک را نمی‌گیرد. سپس تصمیم انتشار را به نسخه مدل، پرامپت، مسیر ابزار و تنظیمات اندازه‌گیری وصل کنید؛ همان مسئله‌ای که در کنترل تغییر و انتشار تدریجی بررسی کرده‌ایم.

پس از تغییر مسیریاب، شیوه ثبت شاخص، مرز سبدها یا سهم گروه‌های درخواست، این مقایسه را بازبینی کنید. یک گزارش خوب فقط عدد بهتری نشان نمی‌دهد؛ روشن می‌کند کدام کار، برای کدام گروه، با چه نرخ موفقیتی سریع‌تر شده و کدام بخش هنوز نامعلوم است.

منابع و یادداشت بررسی — ۴ اکتبر ۲۰۲۶

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

• Prometheus — هیستوگرام و خلاصه‌ها: مستند زنده؛ محدودیت تجمیع صدک و دقت سبدها.
• NIST — صدک‌ها: بخش راهنمای آماری بدون تاریخ انتشار مشخص در صفحه؛ ترتیب مشاهده‌ها و روش‌های برآورد.
• OpenTelemetry — مدل داده شاخص‌ها: مشخصات زنده؛ بخش‌های پایدار هیستوگرام و نحوه انباشت زمانی.
• Google SRE — پایش سامانه‌های توزیع‌شده: فصل کتاب؛ تمایز تأخیر پاسخ موفق و خطا.
• Grafana k6 — مدل‌های باز و بسته: مستند زنده؛ رابطه زمان اجرا و نرخ ورود بار.