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

ספריית הלקוח של 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 בלי קשר לגודל הדוח. השימוש ב-Search בדרך כלל משפר את הביצועים בהשוואה להחלפת דפים, כי הוא מבטל את זמן הלוך ושוב ברשת שנדרש כדי לבקש כל דף בנפרד בתגובה של SearchStream. במדריך לדוחות סטרימינג מוסבר מתי כדאי לבחור בכל אחת מהשיטות.

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

בסביבות מסוימות בלי שמירת מצב, כמו 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 להפצה

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

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

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

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

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

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

אפשר להשתמש בפרמטר callSettings כדי להעביר CancellationToken לשיטות אסינכרוניות כמו 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.V25.GoogleAdsService);

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

השבתת הרישום ביומן כשניתן

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

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

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

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

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

שימוש ב-TieredCompilation

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

שיפור מנגנון איסוף הזבל (GC)

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

זהירות: הפעלה של ServerGarbageCollection או RetainVMGarbageCollection בסביבות עם מגבלות על המשאבים (כמו קונטיינרים קטנים של Docker או פונקציות בלי שרת) עלולה להגדיל באופן משמעותי את צריכת הזיכרון ולגרום לשגיאות של חוסר זיכרון. חשוב להשוות את הזיכרון שבשימוש של האפליקציה לפני שמפעילים את ההגדרות האלה בסביבות בקונטיינרים.

כדאי לבצע אופטימיזציה של ההגדרות הבאות של איסוף נתונים:

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

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

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

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

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

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

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