ביצועים

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

רוב השיטות המומלצות הכלליות רלוונטיות לכל השפות. במדריך הזה מוסבר איך לבצע אופטימיזציה של הביצועים ב-PHP.

הטמעות של Protobuf ו-gRPC

‫Protobuf משמש את gRPC ואת Google Ads API להודעות של בקשות ותגובות. יש שתי הטמעות זמינות (PHP טהור ותוסף C), ותוספי ה-C של protobuf ושל grpc מספקים ביצועי רשת וסריאליזציה טובים בהרבה.

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

מצב הפעולה של מפענח ה-PHP

PHP היא שפת סקריפטים רב-תכליתית, ויש לה כמה מצבי פעולה בהתאם לשימוש. ל-PHP-FPM (מנהל תהליכים של FastCGI) או לשרתי אפליקציות קבועים יש יתרון משמעותי על פני CGI רגיל, כי תהליכי עבודה קבועים יכולים לעשות שימוש חוזר ב-bytecode שנשמר במטמון (באמצעות OPcache) ובמשאבים בבקשות שונות.

גרסת PHP

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

גרסאות של Google Ads API שלא בשימוש

כל הגרסאות של ספריית הלקוח תומכות בכמה גרסאות של Google Ads API. לכל גרסה של Google Ads API שנתמכת על ידי ספריית הלקוח, יש חבילות ייעודיות לאותה גרסה.

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

אזהרה: הפעולה הזו מסירה קבצים בתוך הספרייה vendor, ואי אפשר לבטל אותה בקלות בלי להתקין מחדש את החבילות. חשוב לזכור שאם תריצו את composer install או את composer update מאוחר יותר, הקבצים שהוסרו ישוחזרו, אלא אם תגדירו את הסקריפט הזה בקטעים post-install-cmd ו-post-update-cmd בקובץ composer.json.

דוגמה

נניח שאתם מטמיעים אפליקציית לקוח שמשתמשת רק בגרסת ה-API האחרונה (v26), ואתם רוצים להסיר את התמיכה בגרסאות ה-API שלא נמצאות בשימוש (v23,‏ v24 ו-v25).

הערה: כל גרסה של google-ads-php כוללת ספריות לגרסאות ה-API העיקריות הנתמכות (כמו V26, עם גרסאות משניות כמו v25.1 שנכללות ב-V25).

בקובץ composer.json של הפרויקט, מגדירים סקריפט של Composer (בשם remove-google-ads-api-version-support) שמשתמש בכלי שספריית הלקוח מספקת ב-ApiVersionSupport:

"scripts": {
  "remove-google-ads-api-version-support": [
    "Google\\Ads\\GoogleAds\\Util\\ApiVersionSupport::remove"
  ]
}

לאחר מכן, מריצים את סקריפט Composer עם מספרי הגרסאות כפרמטרים ומדפיסים הודעות סטטוס:

# Change the current directory to the project directory.
cd /path/to/the/project

# Install the project.
composer install

# Output the vendor folder size and the list of Google Ads API versions that are
# supported before removing support for unused Google Ads API versions.
echo "# Supported Google Ads API versions:"
find ./vendor/googleads/google-ads-php/src/Google/Ads/GoogleAds/V* \
  -maxdepth 0 | grep -oE 'V[0-9]+$'
echo "# Vendor folder size:"
du -sh ./vendor

# Use the Composer script to remove the unused versions
# v23, v24, and
# v25 of the Google Ads API.
echo "# Removing support..."
composer run-script remove-google-ads-api-version-support -- \
  23 \
  24 \
  25

# Output the vendor folder size and the list of Google Ads API versions that are
# supported after removing support for unused Google Ads API versions.
echo "# Supported Google Ads API versions:"
find ./vendor/googleads/google-ads-php/src/Google/Ads/GoogleAds/V* \
  -maxdepth 0 | grep -oE 'V[0-9]+$'
echo "# Vendor folder size:"
du -sh ./vendor

בפלט לדוגמה של ההרצה הבאה מוצגת ההפחתה בגודל הקובץ, כאשר V26 היא הגרסה הנתמכת היחידה שנותרה:

# Supported Google Ads API versions:
V23
V24
V25
V26
# Vendor folder size:
135M    ./vendor
# Removing support...
> Google\Ads\GoogleAds\Util\ApiVersionSupport::remove
Removing support for the version 23 of Google Ads API...
Done
Removing support for the version 24 of Google Ads API...
Done
Removing support for the version 25 of Google Ads API...
Done
# Supported Google Ads API versions:
V26
# Vendor folder size:
60M     ./vendor

הערה: אם אתם מפתחים בפרויקט של ספריית הלקוח עצמה, כבר מוגדר סקריפט של Composer לנוחיותכם: remove-api-version-support.

פיתוח לעומת ייצור

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

מטמון

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

‫OPcache הוא הפתרון הסטנדרטי והוא כלול ב-PHP כברירת מחדל.

טעינה אוטומטית

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

ספריית הלקוח של PHP תואמת ל-PSR-4 לטעינה אוטומטית, ומספקת את ההגדרה כחלק מקובץ composer.json שלה. אחר כך אפשר להשתמש באפשרויות ייעודיות של Composer CLI, כמו --optimize-autoloader או --classmap-authoritative, בגרסאות ייצור.

רישום ביומן

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

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

ניפוי באגים ויצירת פרופילים

השביתו את תוספי מנפה הבאגים והפרופיילר (כמו Xdebug) בסביבת הייצור, כי הם מוסיפים תקורה משמעותית לביצוע.

טעינה מראש

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

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