عملکرد URL
جدول تأخیر برای هر URL، گروه‌بندی‌شده بر اساس URL کامل درخواست، با میانگین، p50، p95، بیشینه و تعداد خطا تا صفحه‌ها و endpointهای کند را دقیق پیدا کنید.
عملکرد URL جدولی از تأخیر هر URL است که درخواست‌ها را بر اساس URL کامل HTTP گروه‌بندی می‌کند (نه بر اساس نام منطقی عملیات). مکمل کارت عملیات (تأخیر API) است: عملیات بر اساس نام عملیات جمع می‌شوند (GET /users/:id)، اما URLها بر اساس چیزی که مرورگر کاربر واقعاً درخواست کرده (/users/4710). وقتی لازم دارید بدانید کدام صفحه‌های مشخص کندند، نه فقط کدام routeها، از این استفاده کنید.
برای routeهای بک‌اند (مسیرهای پارامتری) از عملیات استفاده کنید. برای فراخوانی‌های سمت کلاینت در هر صفحه، یا وقتی اصلاً قالب route ندارید (مثل فایل‌های استاتیک و فراخوانی‌های ثالث)، از عملکرد URL استفاده کنید.
داده‌ها شامل چه چیزی است#
هر ردیف این ستون‌ها را دارد:
| ستون | توضیح |
|---|---|
| method | متد HTTP (GET، POST، PUT، PATCH، DELETE و …) |
| url | URL کامل درخواست |
| request_count | تعداد کل درخواست‌ها برای این URL در بازه‌ی زمانی انتخاب‌شده |
| avg_duration | میانگین مدت (ms)؛ تقریبی، اما کنار p95 مفید است |
| p50 | میانه؛ تجربه‌ی یک کاربر معمولی |
| p95 | دنباله‌ی کند؛ ۵٪ کندترین درخواست‌ها. بیشتر دردسر کاربر همین‌جاست |
| max_duration | کندترین درخواست در این بازه؛ برای پیدا کردن موارد پرت |
| error_count | تعداد پاسخ‌هایی با وضعیت HTTP 400 یا بالاتر |
ردیف‌ها بر اساس p95 نزولی مرتب می‌شوند تا کندترین‌ها بالا بیایند.
تفاوت URL و عملیات#
این تفاوت موقع خواندن جدول مهم است:
- عملیات یک قالب منطقی route است؛
GET /api/users/:idدر کارت عملیات فقط یک ردیف است، هر شناسه‌ی کاربری که صدا زده شده باشد. - URL همان رشته‌ای است که SDK دیده؛
https://api.example.com/users/4710و/users/4711اینجا دو ردیف جدا هستند.
اگر بک‌اند شما URLهای با تنوع بالا دارد (هر شناسه‌ی کاربر یک ردیف جدا)، جدول عملکرد URL خیلی زود شلوغ می‌شود. این عمدی است: به شما می‌گوید کدام کاربر، رکورد یا صفحه‌ی مشخصی کند است. برای مانیتورینگ کلی در سطح route، کارت عملیات را ترجیح دهید.
الگوهای رایجی که باید زیر نظر بگیرید#
یک URL پرتکرار با p95 خیلی بالاتر از بقیه معمولاً یعنی رکورد مشخصی باعث کوئری N+1 یا ردیف داغ شده است
اگر GET /users/4710، /users/4711 و /users/4712 همه کندند، خود route کند است؛ به کارت عملیات بروید
یک درخواست فاجعه‌بار در میان ترافیک سالم؛ معمولاً کوئری افسارگسیخته یا cache miss نادر. ارزش بررسی دارد
اگر URLهای .js / .css / .png مقدار p95 بالایی دارند، نرخ hit در cache مربوط به CDN پایین آمده است. origin shielding را بررسی کنید
بهترین روش‌ها#
عملیات جواب می‌دهد «آیا این route به‌طور میانگین کند است؟» و عملکرد URL جواب می‌دهد «کندترین درخواست مشخص کدام بود؟»
اگر هر شناسه‌ی کاربر URL جدای خودش باشد، جدول طولانی می‌شود. وقتی خودتان span می‌فرستید، نام عملیات را به شکل قالب route بدهید (مثلاً GET /users/:id) تا در کارت عملیات جمع شوند؛ http_url همچنان مسیر خام را نگه می‌دارد
URL کند را در کارت درخواست‌های ناموفق پیدا کنید تا موارد خطای مشخص را ببینید
یک بیشینه‌ی ۸ ثانیه یا بیشتر ارزش بررسی دقیق دارد؛ اغلب باگی را نشان می‌دهد که p95 به‌تنهایی نمی‌بیند
URLی با ۱۰٬۰۰۰ درخواست و p95 برابر 300ms بیشتر از URLی با ۵۰ درخواست و p95 برابر 1.5s روی کاربران اثر دارد. هر دو مهم‌اند؛ بر اساس دامنه‌ی اثر وزن بدهید