Biblioteka klienta PHP ułatwia interakcję z interfejsem Google Ads API, ponieważ konfiguracja jest minimalna. Wydajność zależy jednak w dużej mierze od tego, jak biblioteka jest używana i integrowana.
Większość sprawdzonych metod dotyczy wszystkich języków. W tym przewodniku omówimy te dotyczące tylko języka PHP.
Implementacja buforów protokołu
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 języku C jest skuteczniejsza.
Więcej informacji znajdziesz w przewodniku po buforach protokołu.
Tryb działania interpretera PHP
PHP to uniwersalny język skryptów, który ma wiele trybów działania w zależności od użycia. CGI (Common Gateway Interface) ma wyjątkową zaletę, ponieważ umożliwia współdzielenie zasobów między uruchomieniami.
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 istnieją specjalne pakiety dla tej wersji.
Pakiety przeznaczone dla nieużywanych wersji interfejsu Google Ads API można bezpiecznie usunąć z biblioteki klienta. Biblioteka klienta może przyspieszyć działanie lub zmniejszyć ilość pamięci, dlatego w bibliotece klienta znajdują się narzędzia, dzięki którym zrobisz to automatycznie.
Przykład
Załóżmy, że wdrażasz bibliotekę klienta, która używa tylko najnowszej wersji interfejsu API: v17, i chcesz wyłączyć obsługę nieużywanych wersji interfejsu API: v16 i v15.
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, podając numery wersji jako parametry i wydrukuj komunikaty o stanie:
# 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 v15 and v16 of the Google Ads API.
echo "# Removing support..."
composer run-script remove-google-ads-api-version-support -- 15 16
# 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
Przykładowe wyniki wykonania kodu poniżej wskazują, że rozmiar pliku został zmniejszony o 50 MB, a pozostała obsługiwana wersja to V17:
# Supported Google Ads API versions:
V15
V16
V17
# Vendor folder size:
110M ./vendor
# Removing support...
> Google\Ads\GoogleAds\Util\ApiVersionSupport::remove
Removing support for the version 15 of Google Ads API...
Done
Removing support for the version 16 of Google Ads API...
Done
# Supported Google Ads API versions:
V17
# Vendor folder size:
60M ./vendor
Programowanie a produkcja
Jest to język interpretowany, ponieważ kompiluje instrukcje przed ich wykonaniem. Jest to zazwyczaj korzystne, ponieważ w czasie programowania źródła często się zmieniają, podczas gdy czas wykonywania nie jest aż 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.
Najczęściej używane rozwiązanie to OPcache. Jest ono dostępne domyślnie.
Automatyczne doładowanie
Automatyczne wczytywanie jest powszechne, ponieważ zwiększa wydajność i stabilność przez wczytywanie wstępnie skompilowanych informacji o klasach.
Biblioteka klienta PHP jest zgodna ze standardem PSR-4 w przypadku automatycznego ładowania i przekazuje definicję do pliku composer.json. Od razu możesz używać specjalnych opcji Composer, takich jak --optimize-autoloader czy --classmap-authoritative.
Logowanie
Ustawienie rejestratorów na wysokim poziomie, takim jak ERROR, może zmniejszyć czas wykonywania i wykorzystanie pamięci.
Więcej informacji znajdziesz w przewodniku dotyczącym logowania.
Debugowanie i profilowanie
Zalecamy wyłączenie debugera i narzędzi do profilowania, ponieważ zwykle wiążą się one z pewnym nakładem czasu wykonywania.
Wczytaj wstępnie
Od wersji PHP 7.4 funkcja OPcache wstępne wczytywanie można używać do wstępnego wczytywania skryptów w pamięci, co jest o krok dalej niż w przypadku zwykłego buforowania.
Skrypt musi zostać zaprojektowany, aby wykorzystać tę funkcję, ale biblioteka klienta PHP tak nie działa, ponieważ nie ma ogólnego sposobu implementacji wstępnego wczytywania OPcache, a kompromis między wykorzystaniem pamięci a wzrostem wydajności jest ściśle uzależniony od konkretnego projektu i wykonania.