Biblioteka klienta PHP ułatwia interakcję z interfejsem Google Ads API przy minimalnym wysiłku. z Twojej strony. Jednak wydajność zależy głównie od sposobu korzystania z biblioteki i jej integracji.
Większość tych sprawdzonych metod ma zastosowanie we wszystkich językach. W tym przewodniku omówiono te, które dotyczą PHP.
Implementacja protokołu protobuf
Protobuf jest używany przez gRPC i interfejs Google Ads API do przesyłania żądań i odpowiedzi. Dostępne są 2 implementacje, ale ta napisana w C ma lepszą wydajność.
Więcej informacji znajdziesz w przewodniku po buforach protokołu.
Tryb działania interpretera PHP
PHP to uniwersalne skrypty język i obsługuje wiele działań w zależności od użycia. Plik PHP CGI (Common Gateway Interface) ma wyjątkową zaletę, ponieważ umożliwia udostępnianie zasobów między uruchomieniami.
Wersja PHP
Dobrą praktyką jest regularne uaktualnianie do nowszej wersji PHP, tak jak to zwykle zapewnia większą ogólną skuteczność. Lista obsługiwanych wersji PHP
Nieużywane wersje interfejsu Google Ads API
Wszystkie wersje biblioteki klienta obsługują wiele wersji interfejsu Google Ads API. W przypadku każdej wersji interfejsu Google Ads API obsługiwanej przez bibliotekę klienta podano dedykowane pakiety dla danej wersji.
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 korzysta tylko z 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 funkcji udostępnionych 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
Przykładowe wyniki wykonania polecenia poniżej wskazują, że rozmiar pliku został zmniejszony o 50 MB, a
pozostała tylko obsługiwana wersja to 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
PHP jest językiem interpretowanym ponieważ najpierw 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. W czasie produkcji jest jednak odwrotnie, ponieważ stabilność i wydajność stają się głównymi problemami.
Cache (Pamięć podręczna)
Pamięć podręczna jest powszechna i zdecydowanie zalecana, ponieważ zwiększa wydajność. i zwiększa 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. Wtedy można używać gotowych opcji Composera, takich jak --optimize-autoloader lub --classmap-authoritative.
Logowanie
Ustawienie rejestratorów na wysokim poziomie, np. ERROR, może pomóc w zredukowaniu czasu wykonania, obciążenia i zużycia pamięci.
Więcej informacji znajdziesz w przewodniku dotyczącym logowania.
Debugowanie i profilowanie
Zalecamy wyłączenie debugera i narzędzia do profilowania, które zwykle są i zwiększyć czas oczekiwania na wykonanie.
Wczytaj wstępnie
Od wersji PHP 7.4 OPcache wstępne ładowanie można użyć do wstępnego wczytywania skryptów w pamięci, i to znacznie dalej niż w przypadku zwykłych plików 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 zyskiem na wydajności jest bardzo specyficzny dla danego projektu i wykonania.