Biblioteka klienta PHP ułatwia interakcje z interfejsem Google Ads API przy minimalnej konfiguracji. Jednak wydajność zależy głównie od sposobu korzystania z biblioteki i jej integracji.
Większość tych sprawdzonych metod można stosować we wszystkich językach. W tym przewodniku omówimy te dotyczące tylko języka PHP.
Implementacja protokołu protobuf
Protobuf jest używany przez gRPC i interfejs Google Ads API na potrzeby komunikatów dotyczących żądań i odpowiedzi. Dostępne są 2 implementacje, ale ta napisana w C ma lepszą wydajność.
Więcej informacji znajdziesz w przewodniku po Protobuf.
Tryb działania interpretera PHP
PHP to wszechstronny język skryptowy, który ma wiele trybów działania w zależności od zastosowania. PHP CGI (Common Gateway Interface) ma znaczną przewagę, ponieważ może udostępniać zasoby między wykonaniami.
Wersja PHP
Zaleca się regularne uaktualnianie do nowszej wersji PHP, ponieważ zwykle przynosi to lepsze wyniki. Lista obsługiwanych wersji PHP.
Nieużywane wersje interfejsu Google Ads API
Wszystkie wersje biblioteki klienta obsługują wiele wersji interfejsu Google Ads API. Dla każdej wersji interfejsu Google Ads API obsługiwanej przez bibliotekę klienta dostępne są specjalne pakiety.
Pakiety przeznaczone do nieużywanych wersji interfejsu Google Ads API można bezpiecznie usunąć z biblioteki klienta. Ponieważ może to przyspieszyć wykonywanie kodu lub zmniejszyć zużycie pamięci, biblioteka klienta udostępnia narzędzia do wykonywania tych czynności programowo.
Przykład
Załóżmy, że wdrażasz bibliotekę klienta, która używa tylko najnowszej wersji interfejsu API: v18, i chcesz usunąć obsługę nieużywanych wersji interfejsu API: v17 i v16.
W pliku composer.json projektu zdefiniuj skrypt Composer (o nazwie remove-google-ads-api-version-support), który korzysta z narzędzia udostępnianego przez bibliotekę klienta w klasie ApiVersionSupport:
"scripts": {
"remove-google-ads-api-version-support": [
"Google\\Ads\\GoogleAds\\Util\\ApiVersionSupport::remove"
]
}
Następnie użyj skryptu Composer z numerami wersji jako parametrami i wydrukuj niektóre komunikaty stanu:
# 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 Google Ads API versions.
echo "# Supported Google Ads API versions:"
find ./vendor/googleads/google-ads-php/src/Google/Ads/GoogleAds/V* -maxdepth 0 | grep -o '..$'
echo "# Vendor folder size:"
du -sh ./vendor
# Use the Composer script to remove the unused versions v16 and v17 of the Google Ads API.
echo "# Removing support..."
composer run-script remove-google-ads-api-version-support -- 16 17
# Output the vendor folder size and the list of Google Ads API versions that are
# supported after removing support for Google Ads API versions.
echo "# Supported Google Ads API versions:"
find ./vendor/googleads/google-ads-php/src/Google/Ads/GoogleAds/V* -maxdepth 0 | grep -o '..$'
echo "# Vendor folder size:"
du -sh ./vendor
Poniżej przedstawiono przykładowe dane wyjściowe z wykonania, które wskazują na zmniejszenie rozmiaru pliku o 50 M. Jedyną obsługiwaną wersją jest V18:
# Supported Google Ads API versions:
V16
V17
V18
# Vendor folder size:
110M ./vendor
# Removing support...
> Google\Ads\GoogleAds\Util\ApiVersionSupport::remove
Removing support for the version 16 of Google Ads API...
Done
Removing support for the version 17 of Google Ads API...
Done
# Supported Google Ads API versions:
V18
# Vendor folder size:
60M ./vendor
Wersja rozwojowa a produkcyjna
Jest to język interpretowany, ponieważ kompiluje instrukcje przed ich wykonaniem. Jest to zwykle korzystne, ponieważ w trakcie tworzenia źródła często się zmieniają, a czas wykonywania nie jest tak istotny. Na etapie produkcji występuje jednak sytuacja odwrotna, ponieważ to właśnie stabilność i wydajność stają się głównymi kwestiami.
Cache (Pamięć podręczna)
Pamięć podręczna jest powszechna i wysoce zalecana, ponieważ zwiększa wydajność oraz stabilność dzięki przechowywaniu gotowych instrukcji skryptu.
OPcache to najczęściej używane rozwiązanie, które jest dostępne domyślnie.
Automatyczne doładowanie
Autoload jest powszechny, ponieważ zwiększa wydajność i stabilność dzięki wczytywaniu wstępnie skompilowanych informacji o klasach.
Biblioteka klienta PHP jest zgodna z PSR-4 w zakresie ładowania automatycznego i zawiera definicję w ramach pliku composer.json. W tym celu można użyć dedykowanych opcji Composer, takich jak --optimize-autoloader lub --classmap-authoritative.
Logowanie
Ustawienie rejestratorów na wysokim poziomie, np. ERROR, może pomóc w zredukowaniu czasu wykonywania, obciążenia i zużycia pamięci.
Więcej informacji znajdziesz w przewodniku dotyczącym rejestrowania.
Debugowanie i profilowanie
Zalecamy wyłączenie narzędzi debugera i profilowania, ponieważ zwykle wiąże się to z pewnym obciążeniem czasu wykonania.
Wczytaj wstępnie
Od wersji PHP 7.4 można używać wstępnego wczytywania OPcache do wstępnego wczytywania skryptów do pamięci, co jest krokiem dalej niż zwykłe buforowanie.
Skrypt musi być zaprojektowany tak, aby można było z niego korzystać, ale biblioteka klienta PHP nie jest w stanie tego zrobić, ponieważ nie ma uniwersalnego sposobu implementacji wstępnego wczytywania OPcache, a kompromis między wykorzystaniem pamięci a zwiększeniem wydajności jest bardzo specyficzny dla danego projektu i wykonania.