ביצועים

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

רוב השיטות המומלצות הכלליות רלוונטיות לכל השפות. בדף הזה מפורטות הנחיות לשיפור הביצועים שספציפיות ל-Perl.

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

כדאי ליצור פרופיל של האפליקציה כדי לבדוק את השימוש במעבד (CPU) ובשימוש בזיכרון, ולזהות צווארי בקבוק בביצועים. ‫Devel::NYTProf הוא פרופילר של קוד מקור ב-Perl עם הרבה תכונות, שאפשר להשתמש בו כדי לנתח את זמן הביצוע.

גרסת Perl

כדאי לשדרג באופן קבוע לגרסה חדשה יותר של Perl כדי ליהנות משיפורים בביצועי זמן הריצה. מורידים את הגרסה האחרונה מגרסאות המקור של CPAN Perl ובודקים את הגרסה המינימלית שנדרשת לספרייה בדרישות של קובץ ה-README.

רישום ביומן

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

פרטים נוספים על הגדרת כלי רישום ביומן של סיכומים ופרטים זמינים במדריך לרישום ביומן.

‫SearchStream לעומת חיפוש

ב-Google Ads API יש שתי שיטות עיקריות לאחזור אובייקטים: ‫Search (שמשתמשת בחלוקה לדפים) ו- ‫SearchStream (שמשתמשת בהזרמה). SearchStream מספק ביצועים טובים יותר מ-Search, אבל יש תרחישים מסוימים שבהם עדיף להשתמש ב-Search.

המדריך בנושא סטרימינג כולל השוואה מפורטת בין שתי השיטות.

אופטימיזציה של מטען ייעודי (payload) ואיגום (batching)

כדי לצמצם את התקורה של הרשת ואת צריכת הזיכרון:

  • בשאילתות של Google Ads Query Language‏ (GAQL) כדאי לבקש רק את השדות הספציפיים שהאפליקציה צריכה.
  • לקבץ כמה פעולות שינוי לבקשת mutate אחת במקום לשלוח בקשות נפרדות לכל שינוי.

פסק זמן של HTTP

ספריית הלקוח של Perl מספקת הגדרה לקביעת הזמן הקצוב לתפוגה של HTTP ברמת הלקוח:

my $api_client = Google::Ads::GoogleAds::Client->new({
  # Set HTTP timeout to 5 minutes (300 seconds).
  http_timeout => 300,
});

ערך ברירת המחדל הוא 3600 שניות (שעה אחת), שמוגדר על סמך הקבוע DEFAULT_HTTP_TIMEOUT ב-Constants.pm. הגדרת זמן קצוב לתפוגה מותאם אישית ללקוח אם צריך להגביל את הזמן המקסימלי לקריאה ל-API.

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