بهینه‌سازی عملکرد با شناسایی سنجه‌های کلیدی شروع می‌شود که معمولاً به تأخیر و توان عملیاتی مربوط است. افزودن نظارت برای ضبط و پیگیری این سنجه‌ها نقاط ضعف برنامه را آشکار می‌کند. با سنجه‌ها، می‌توان بهینه‌سازی را برای بهبود سنجه‌های عملکرد انجام داد.
علاوه‌براین، بسیاری‌از ابزارهای پایش به شما امکان می‌دهند برای سنجه‌هایتان هشدار تنظیم کنید تا وقتی به آستانه خاصی رسیدید مطلع شوید. برای مثال، می‌توانید
هشداری تنظیم کنید تا وقتی درصد درخواست‌های ناموفق
بیش‌از X% سطح عادی افزایش یافت به شما اطلاع داده شود. ابزارهای نظارت می‌توانند به شما کمک کنند تا عملکرد عادی را شناسایی کنید و جهش‌های غیرعادی در تأخیر، تعداد خطاها، و سایر سنجه‌های کلیدی را تشخیص دهید. توانایی نظارت بر این سنجه‌ها به‌ویژه در بازه‌های زمانی حیاتی کسب‌وکار یا پس‌از ارسال کد جدید به تولید اهمیت دارد.
شناسایی سنجه‌های تأخیر
مطمئن شوید که واسط کاربری‌تان را تا حد امکان کنش‌پذیر نگه می‌دارید و توجه داشته باشید که کاربران از برنامه‌های تلفن همراه استانداردهای بالاتری را انتظار دارند. تأخیر نیز باید برای سرویس‌های پسین اندازه‌گیری و ردیابی شود، به‌ویژه ازآنجایی‌که اگر کنترل نشود، می‌تواند منجر به مشکلات توان عملیاتی شود.
سنجه‌های پیشنهادی برای پیگیری شامل موارد زیر است:
- مدت درخواست
- مدت درخواست در دانه‌بندی زیرسیستم (مانند فراخوانی‌های API)
- مدت کار
شناسایی سنجه‌های توان عملیاتی
توان عملیاتی معیاری برای تعداد کل درخواست‌های ارائه‌شده در یک دوره زمانی مشخص است. توان عملیاتی می‌تواند تحت‌تأثیر تأخیر زیرسیستم‌ها قرار گیرد، بنابراین ممکن است لازم باشد تأخیر را بهینه‌سازی کنید تا توان عملیاتی بهبود یابد.
در اینجا چند سنجه پیشنهادی برای پیگیری آورده شده است:
- پُرسمان در ثانیه
- اندازه داده‌های منتقل‌شده در ثانیه
- تعداد عملیات ورودی/خروجی در ثانیه
- استفاده از منابع، مانند استفاده از واحد پردازش مرکزی یا حافظه
- اندازه کارهای معوقه پردازش، مانند pub/sub یا تعداد رشته‌ها
نه فقط میانگین
یک اشتباه رایج در اندازه‌گیری عملکرد، فقط نگاه کردن به حالت میانگین (متوسط) است. اگرچه این مفید است، اما اطلاعات آماری درباره توزیع تأخیر ارائه نمی‌دهد. سنجه بهتر برای ردیابی، صدک‌های عملکرد است، برای مثال صدک‌های ۵۰، ۷۵، ۹۰، و ۹۹ برای یک سنجه.
به‌طور کلی، بهینه‌سازی را می‌توان در دو مرحله انجام داد. ابتدا، برای تأخیر صدک نودم بهینه‌سازی کنید. سپس، صدک ۹۹ را درنظر بگیرید—که به‌عنوان تأخیر دنباله نیز شناخته می‌شود: بخش کوچکی از درخواست‌ها که تکمیل آن‌ها بسیار بیشتر طول می‌کشد.
پایش سمت سرور برای نتایج دقیق
نمایه‌سازی سمت سرور معمولاً برای ردیابی سنجه‌ها ترجیح داده می‌شود. سمت سرور معمولاً برای ابزارسازی بسیار آسان‌تر است، امکان دسترسی به داده‌های دقیق‌تر را فراهم می‌کند، و کمتر درمعرض اختلال ناشی از مشکلات اتصال است.
پایش مرورگر برای رؤیت‌پذیری سرتاسری
اگر ادغام Google Ads API شما یک وب فرانت‌اند به کاربران نهایی ارائه می‌دهد، نمایه‌سازی مرورگر می‌تواند اطلاعات بیشتری درباره تجربه کاربری ارائه دهد. این ابزار می‌تواند نشان دهد کدام صفحه‌ها درخواست‌های کند دارند، سپس می‌توانید این اطلاعات را با پایش سمت سرور برای تحلیل بیشتر مرتبط کنید.
Google Analytics همچنین نظارت آماده‌ای برای زمان بارگیری صفحه در گزارش زمان‌بندی صفحه Analytics ارائه می‌دهد. این چند نمای مفید برای درک تجربه کاربر در سایتتان ارائه می‌دهد، به‌ویژه:
- مدت زمان بار کردن صفحه
- مدت زمان بار شدن تغییر مسیر
- زمان‌های پاسخ سرور
درحال پایش در ابر
ابزارهای زیادی وجود دارد که می‌توانید برای ضبط و پایش سنجه‌های عملکرد برنامه‌تان از آن‌ها استفاده کنید. برای مثال، می‌توانید از Google Cloud Logging برای ثبت سنجه‌های عملکرد در Google Cloud Project استفاده کنید، سپس داشبوردهایی در Google Cloud Monitoring برای نظارت و بخش‌بندی سنجه‌های ثبت‌شده راه‌اندازی کنید.
برای مشاهده
نمونه رهگیر ثبت گزارش gRPC سفارشی که برای
کتابخانه کارخواه Python نوشته شده است، به راهنمای ثبت گزارش مراجعه کنید. در این مثال، رهگیر
logger.log_struct() را فراخوانی می‌کند تا فرهنگ لغت Python داده‌های گزارش ساختاریافته را به
Cloud Logging ارسال کند، که Cloud Logging آن را در فیلد jsonPayload ورودی گزارش ذخیره می‌کند:
logger.log_struct({
"method": method_name,
"elapsed_ms": elapsed_milliseconds,
"is_fault": is_fault,
})
با دردسترس بودن آن داده‌ها در Google Cloud، می‌توانید سنجه‌هایی را روی داده‌های ثبت‌شده بسازید تا ازطریق Google Cloud Monitoring به برنامه‌تان دید داشته باشید. راهنمای معیارهای مبتنی بر گزارش تعریف‌شده توسط کاربر را دنبال کنید تا بااستفاده از گزارش‌های ارسال‌شده به Google Cloud Logging، معیار بسازید.
می‌توانید از کتابخانه‌های مشتری Cloud Monitoring هم برای تعریف سنجه‌ها در کدتان استفاده کنید و آن‌ها را مستقیماً و جدا از گزارش‌ها به Monitoring ارسال کنید.
نمونه سنجه‌های مبتنی بر گزارش
فرض کنید می‌خواهید مقدار is_fault را پایش کنید تا نرخ خطا را در برنامه‌تان بهتر درک کنید. چون logger.log_struct() فیلدهای واژه‌نامه ساختاریافته را در زیر jsonPayload در هر ورودی Cloud Logging می‌نویسد، می‌توانید سنجه شمارنده با نام ErrorCount با فیلتری که با درخواست‌های ناموفق مطابقت دارد، مانند jsonPayload.is_fault = true، ایجاد کنید.
در Cloud Logging، برچسب‌ها به شما امکان می‌دهند سنجه‌هایتان را براساس داده‌های دیگر در گزارش‌ها به دسته‌هایی تقسیم کنید. می‌توانید برچسب STRING
به‌نام Method را در فیلد jsonPayload.method
ارسال‌شده به Cloud Logging پیکربندی کنید تا تعداد خطاها را براساس
روش Google Ads API تفکیک کنید.
با پیکربندی سنجه ErrorCount و برچسب Method، می‌توانید
نمودار جدیدی در Cloud Monitoring ایجاد کنید تا
ErrorCount را که براساس Method گروه‌بندی شده است پایش کنید.
هشدارها
در Cloud Monitoring و ابزارهای دیگر می‌توان خط‌مشی‌های هشدار را پیکربندی کرد که مشخص می‌کنند چه زمانی و چگونه هشدارها باید توسط سنجه‌های شما راه‌اندازی شوند. برای دستورالعمل‌های راه‌اندازی هشدارهای Cloud Monitoring، راهنمای هشدار دادن درباره سنجه‌های مبتنی بر گزارش را دنبال کنید.