ביצועי אפליקציות

ספריית הלקוח של Google Ads ל-‎ .NET מפשטת את האינטראקציות של האפליקציה עם Google Ads API, ודורשת הגדרה מינימלית. עם זאת, הביצועים הכוללים תלויים מאוד באופן השימוש בספרייה ובשילוב שלה באפליקציה.

המדריך הזה עוסק באופטימיזציות של ביצועים שספציפיות לאפליקציות ‎ .NET, ומשלים את השיטות המומלצות שרלוונטיות באופן כללי ל-Google Ads API.

שימוש חוזר ב-GoogleAdsClient כשאפשר

‫GoogleAdsClient מייצג סשן של משתמש כשמבצעים קריאות ל-API. הוא מספק אופטימיזציות כמו:

• שמירה במטמון של ערוצי ה-gRPC שמשמשים את שירותי ה-API. כך אפשר לקצר את זמן ההגדרה כשמבצעים קריאות ראשוניות ל-API.
• שימוש חוזר בטוקני גישה כשאפשר. כך מצמצמים את מספר הנסיעות הלוך ושוב שספריית הלקוח של Google Ads ב-‎ .NET צריכה לבצע כדי לרענן את טוקני הגישה.

אם אפשר, השתמשו בטוקני גישה מחשבון ברמת ניהול

אם יש לכם טוקן גישה שהונפק ברמת חשבון הניהול, אתם יכולים להשתמש בו כדי לבצע קריאות ל-API בכל חשבונות הלקוח ב-Google Ads שנמצאים מתחת לחשבון הזה בהיררכיה. בשילוב עם שימוש חוזר במכונות של GoogleAdsClient, אפשר לצמצם עוד יותר את מספר הנסיעות הלוך ושוב שספריית הלקוח צריכה לבצע כדי לרענן את טוקני הגישה.

כדאי להשתמש ב-SearchStream במקום ב-Search בכל פעם שאפשר

ב-Google Ads API יש שתי דרכים עיקריות לאחזר אובייקטים: GoogleAdsService.Search (שמשתמשת בדפדוף) ו- GoogleAdsService.SearchStream (שמשתמשת בסטרימינג).

בזמן ש-Search שולח כמה בקשות עם חלוקה לדפים כדי להוריד דוח שלם, SearchStream שולח בקשה אחת ויוצר חיבור קבוע עם Google Ads API, בלי קשר לגודל הדוח. ב-SearchStream לא צריך להמתין לזמן הלוך ושוב של הרשת כדי לבקש כל דף בנפרד בתגובה של Search, ולכן בדרך כלל הביצועים טובים יותר מאשר בדפדוף. במדריך לסטרימינג של דוחות מוסבר מתי כדאי לבחור בכל שיטה.

ניהול ידני של רענון טוקני גישה

בסביבות מסוימות ללא שמירת מצב (stateless), כמו Google Cloud Functions, יכול להיות שלא יהיה אפשר להשתמש שוב במכונות של GoogleAdsClient בין קריאות. בסביבות כאלה יש שיטות מומלצות משלהן לשמירה על נתונים ולשימוש חוזר בהם.

ב-Google.Ads.GoogleAds v27.0.0 ואילך, אתם יכולים להוסיף מכונה מוגדרת מראש של ICredential ישירות ב-GoogleAdsConfig באמצעות המאפיין Credentials ולהשבית את השמירה במטמון של הערוץ (UseChannelCache = false).

אם אתם מעדיפים להכיל את יצירת פרטי הכניסה במחלקת הגדרות אישית (או אם אתם משתמשים בגרסה קודמת של הספרייה), אתם יכולים להרחיב את המחלקה GoogleAdsConfig כדי לבצע רענון של טוקני הגישה שלכם באופן הבא:

// Create your own config class by extending the GoogleAdsConfig class.
class MyGoogleAdsConfig : GoogleAdsConfig
{
    public MyGoogleAdsConfig() : base()
    {
        // Disable the library's built-in channel caching mechanism.
        UseChannelCache = false;
    }

    protected override ICredential CreateCredentials()
    {
        // Create your own ICredential object here. You may refer to the
        // default implementation of GoogleAdsConfig.CreateCredentials
        // for an example.
    }
}

// Use your own config class when initializing the GoogleAdsClient instance.
MyGoogleAdsConfig myConfig = new MyGoogleAdsConfig();
GoogleAdsClient client = new GoogleAdsClient(myConfig);

הידור לגרסת build להפצה

חשוב לוודא שאתם מקמפלים את האפליקציה באמצעות Release configuration כשאתם פורסים אותה בשרת. כשמשתמשים בהגדרת ניפוי הבאגים, האפליקציה עוברת קומפילציה עם מידע סמלי מלא על תוצאות ניפוי הבאגים ובלי אופטימיזציות של הקומפיילר.

יצירת פרופיל לאפליקציה

כדי לזהות צווארי בקבוק בביצועים, כדאי ליצור פרופיל של האפליקציה גם לשימוש במעבד (CPU) וגם לשימוש בזיכרון. ב-Visual Studio יש כלי אבחון שעוזרים ליצור פרופיל לאפליקציה. יש גם כלים מסחריים אחרים ליצירת פרופילים.

שימוש בשיטות אסינכרוניות

תכנות אסינכרוני באמצעות פרדיגמת async-await עוזר למנוע צווארי בקבוק בביצועים ומשפר את התגובה הכוללת של האפליקציה. ספריית Google Ads .NET יוצרת שיטות אסינכרוניות לכל השירותים ושיטות RPC.

ביטול שיטות אסינכרוניות

אפשר להשתמש בפרמטר callSettings כדי להעביר CancellationToken ל-methods אסינכרוניות כמו SearchStreamAsync:

using CancellationTokenSource cancellationTokenSource =
    new CancellationTokenSource();
cancellationTokenSource.CancelAfter(3000);
CallSettings callSettings =
    CallSettings.FromCancellationToken(cancellationTokenSource.Token);

string query = "SELECT campaign.name FROM campaign";
var request = new SearchGoogleAdsStreamRequest()
{
    CustomerId = customerId.ToString(),
    Query = query,
};

GoogleAdsServiceClient googleAdsService = client.GetService(
    Services.V26.GoogleAdsService);

await googleAdsService.SearchStreamAsync(
    request,
    (SearchGoogleAdsStreamResponse resp) =>
    {
        foreach (GoogleAdsRow googleAdsRow in resp.Results)
        {
            // Process the row.
        }
    },
    callSettings);

השביתו את הרישום ביומן כשאפשר

ספריית Google Ads .NET משביתה את הרישום ביומן כברירת מחדל ומשתמשת בגישת רישום ביומן מסוג lazy logging, שמשפרת את ביצועי האפליקציה. אם אתם מפעילים את הרישום ביומן במהלך הפיתוח, הקפידו להשבית אותו בסביבת הייצור. אם אתם צריכים לעקוב אחרי בקשות ספציפיות שנכשלו בסביבת הייצור, אתם יכולים לבצע אחת או יותר מהפעולות הבאות בלי להשפיע לרעה על ביצועי האפליקציה:

• מפעילים רק את יומני הסיכום.
• מגדירים את היומנים המלאים לרמה ERROR.
• שמרו את מזהה הבקשה של בקשות ספציפיות שנכשלו כדי שתוכלו לשתף אותו עם ערוצי התמיכה.

מידע נוסף זמין במדריך הרישום ביומן.

שימוש באפשרות ReadyToRun

בגרסאות מודרניות של ‎ .NET אפשר להגדיר את PublishReadyToRun ל-true כדי להדר מראש את הקבצים הבינאריים לפלטפורמה ולארכיטקטורה ספציפיות, ואז לפרסם את הקובץ הבינארי על ידי ציון RuntimeIdentifier חוקי. מידע נוסף זמין במדריך הפריסה של ReadyToRun.

שימוש ב-TieredCompilation

TieredCompilation (מופעלת כברירת מחדל בגרסאות מודרניות של ‎ .NET כמו ‎ .NET 8) מאפשרת ל-‎ .NET לזהות נקודות חמות ולשפר את הביצועים בזמן הריצה. הידור מדורג עובד טוב עם ReadyToRun כי הוא יכול להשתמש בתמונה שנוצרה מראש להפעלה מהירה, ואז לקמפל מחדש שיטות חמות עם אופטימיזציות מלאות. מידע נוסף זמין במדריך של TieredCompilation.

כוונון עדין של איסוף הזבל (GC)

ב-‎.NET יש שני פרופילים כלליים לאיסוף אשפה (GC): פרופיל תחנת עבודה ופרופיל שרת. לשני הפרופילים האלה יש השפעות שונות על הביצועים. אפליקציות ייעודיות לשרתים שמשתמשות בספריית ‎ .NET של Google Ads בדרך כלל פועלות טוב יותר כשהן פועלות בפרופיל שרת.

כדאי לשנות את ההגדרות הבאות של GC:

• איסוף פסולת בשרת: איסוף פסולת בשרת מאפשר לזמן הריצה של .NET לספק תפוקה גבוהה יותר לאפליקציית Google Ads API על ידי פעולה על מספר ערימות GC והליכים. פרטים נוספים זמינים במדריך ל-GC בשרת. ניתן להפעיל את איסוף האשפה של השרת על ידי הוספת השורות הבאות לקובץ .csproj של האפליקציה שלך:

  <PropertyGroup>
    <ServerGarbageCollection>true</ServerGarbageCollection>
  </PropertyGroup>
  

• איסוף אשפה מקביל: ניתן להפעיל את איסוף האשפה המקביל כדי לתת ל-.NET GC רצף ייעודי לאיסוף אשפה בדור 2. ההגדרה הזו יכולה להיות שימושית כשמעבדים דוחות גדולים. ניתן להפעיל איסוף אשפה בו-זמני על ידי הוספת השורות הבאות לקובץ .csproj של האפליקציה שלך:

  <PropertyGroup>
    <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
  </PropertyGroup>
  

• שמירת איסוף של VM: ההגדרה RetainVMGarbageCollection קובעת אם מקטעים של זיכרון וירטואלי שצריך למחוק יועברו לרשימת המתנה לשימוש עתידי, או ישוחררו בחזרה למערכת ההפעלה (OS). כדי להפעיל את שמירת הזיכרון הווירטואלי, צריך להוסיף את השורות הבאות לקובץ .csproj של האפליקציה:

  <PropertyGroup>
    <RetainVMGarbageCollection>true</RetainVMGarbageCollection>
  </PropertyGroup>
  

כדי לשפר את ה-GC, אתם יכולים לבחור הגדרה שמאזנת בין ההתנהגות של תחנת העבודה לבין ההתנהגות של השרת. אפשר לציין את כל ההגדרות הרלוונטיות של GC בקובץ runtimeconfig.json של אפליקציית ‎ .NET, באמצעות משתני סביבה או ב-App.config.