بازبینی

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

علاوه‌براین، بسیاری از ابزارهای پایش به شما امکان می‌دهند برای سنجه‌هایتان هشدار تنظیم کنید تا وقتی آستانه معینی برآورده شد، مطلع شوید. برای مثال، می‌توانید هشداری تنظیم کنید تا وقتی درصد درخواست‌های ناموفق بیش‌از 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، راهنمای هشدار دادن درباره سنجه‌های مبتنی بر گزارش را دنبال کنید.