مانیتورینگ زمان پاسخ: چی رو اندازه بگیریم و کی هشدار بدیم.

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

نکته‌های کلیدی

• زمان پاسخ مجموع چند مرحله است: DNS، اتصال TCP، TLS، پردازش سرور و انتقال.
• صدک‌ها یا بازه‌ها رو دنبال کنید، نه فقط میانگین؛ میانگین درخواست‌های کندی رو که کاربر حس می‌کنه قایم می‌کنه.
• لوکیشن‌ها رو مقایسه کنید: کندی از یه شهر و نه بقیه، به شبکه اشاره می‌کنه نه سرور.
• روی کندی پایدار بالای یه حد هشدار بدید، جدا از قطعی.
• بعد از هر دیپلوی روند رو ببینید؛ کند شدن تدریجی رو زود راحت‌تر می‌شه درست کرد.

اندازه‌گیری زمان پاسخ شامل چیه؟

برای یه چک HTTPS، زمان کل به چند مرحله تقسیم می‌شه:

خودتون هم می‌تونید همین تفکیک رو ببینید:

curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n" https://example.com/

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

میانگین درد رو قایم می‌کنه

اگه ۹۵ درخواست ۲۰۰ میلی‌ثانیه و ۵ درخواست ۶ ثانیه طول بکشن، میانگین حدود ۴۹۰ میلی‌ثانیه می‌شه؛ که تجربه‌ی هیچ‌کس رو توصیف نمی‌کنه. نماهای بهتر:

• صدک‌ها (p50، p95، p99): «۹۵٪ چک‌ها سریع‌تر از X بودن».
• باند حداقل/حداکثر در هر ساعت، که جهش‌ها رو نشون می‌ده.
• خط جدا برای هر لوکیشن، که نشون می‌ده یه منطقه آسیب می‌بینه یا نه.

استفاده از لوکیشن‌ها برای پیدا کردن علت

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

تنظیم هشدار کندی

1. یه هفته‌ی عادی رو نگاه کنید و مقدارهای معمول و اوج رو یادداشت کنید.
2. یه حد بذارید که خیلی بالاتر از اوج‌های عادی باشه؛ مثلاً ۲ تا ۳ برابر p95 معمول.
3. پایداری رو شرط کنید؛ چند چک کند پشت‌سرهم، تا یه جهش تکی هشدار نده.
4. اون رو به کانال تیم بفرستید، نه پیجر؛ مگر اینکه کندی سرویس رو غیرقابل استفاده کنه.

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

خوب یعنی چقدر؟

هدف جهانی وجود نداره، ولی برای جهت‌یابی:

• پاسخ سرور (TTFB) زیر ۲۰۰ تا ۵۰۰ میلی‌ثانیه برای صفحه‌های پویا راحته.
• endpointهای APIی که تعاملی استفاده می‌شن معمولاً باید ظرف چند صد میلی‌ثانیه جواب بدن.
• فایل‌های ایستایی که CDN ارائه می‌ده نزدیک لبه باید در چند ده میلی‌ثانیه برسن.

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

پرسش‌های پرتکرار

• چرا اولین چک بعد از یه دوره‌ی آروم کندتره؟

  +

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

• فاصله‌ی چک سریع‌تر داده‌ی زمان پاسخ رو بهتر می‌کنه؟

  +

  نقطه‌های بیشتری می‌ده و جهش‌های کوتاه رو می‌گیره، ولی روندها با فاصله‌ی ۱ تا ۵ دقیقه هم دیده می‌شن.

• روی زمان پاسخ هشدار بدم یا فقط روی قطعی؟

  +

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