La bibliothèque cliente PHP facilite les interactions avec l'API Google Ads avec une configuration minimale de votre part. Toutefois, les performances dépendent fortement de la manière dont la bibliothèque est utilisée et intégrée.
La plupart de ces bonnes pratiques s'appliquent à toutes les langues. Ce guide présente celles qui sont spécifiques à PHP.
Implémentation Protobuf
Protobuf est utilisé par gRPC et l'API Google Ads pour les messages de requête et de réponse. Deux implémentations sont disponibles, mais celle écrite en C offre de meilleures performances.
Pour en savoir plus, consultez le guide Protobuf.
Mode de fonctionnement de l'interpréteur PHP
PHP est un langage de script polyvalent et dispose de nombreux modes de fonctionnement en fonction de l'utilisation. L'interface CGI (Common Gateway Interface) PHP présente un avantage notable, car elle peut partager des ressources entre les exécutions.
Version de PHP
Il est recommandé de passer régulièrement à une version plus récente de PHP, car elle offre généralement de meilleures performances globales. Liste des versions PHP compatibles
Versions inutilisées de l'API Google Ads
Toutes les versions de la bibliothèque cliente sont compatibles avec plusieurs versions de l'API Google Ads. Pour chaque version de l'API Google Ads compatible avec la bibliothèque cliente, il existe des packages dédiés.
Les packages dédiés aux versions de l'API Google Ads qui ne sont pas utilisées peuvent être supprimés en toute sécurité de la bibliothèque cliente. Comme il peut être utile d'accélérer l'exécution ou de réduire l'espace mémoire, la bibliothèque cliente fournit des utilitaires pour le faire de manière programmatique.
Exemple
Supposons que vous implémentiez la bibliothèque cliente qui n'utilise que la dernière version de l'API: v18
, et que vous souhaitiez supprimer la prise en charge des versions d'API inutilisées: v17
et v16
.
Dans le fichier composer.json
du projet, définissez un script Composer (nommé remove-google-ads-api-version-support
) qui exploite l'utilitaire fourni par la bibliothèque cliente, dans la classe ApiVersionSupport
:
"scripts": {
"remove-google-ads-api-version-support": [
"Google\\Ads\\GoogleAds\\Util\\ApiVersionSupport::remove"
]
}
Ensuite, utilisez le script Composer avec les numéros de version comme paramètres et imprimez des messages d'état:
# 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
L'exemple de sortie d'exécution ci-dessous indique une réduction de la taille de fichier de 50 Mo, et la seule version compatible restante est 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
Développement par rapport à la production
PHP est un langage interprété, car il compile d'abord les instructions avant de les exécuter. Cela est généralement avantageux, car pendant le développement, les sources changent souvent, tandis que le temps d'exécution n'est pas si crucial. Cependant, l'inverse est vrai au moment de la production, car la stabilité et les performances deviennent les principales préoccupations.
Cache
La mise en cache est courante et fortement recommandée, car elle améliore à la fois les performances et la stabilité en stockant des instructions de script précompilées.
OPcache est la solution la plus couramment utilisée et est disponible par défaut.
Réapprovisionnement automatique
L'autochargement est courant, car il améliore à la fois les performances et la stabilité en chargeant des informations précompilées sur les classes.
La bibliothèque cliente PHP est conforme à PSR-4 pour l'autoloading et fournit la définition dans le fichier composer.json
. Les options dédiées de Composer, telles que --optimize-autoloader
ou --classmap-authoritative
, peuvent alors être utilisées prêtes à l'emploi.
Journalisation
Définir les enregistreurs à un niveau élevé, comme ERROR
, peut contribuer à réduire les coûts liés au temps d'exécution et à la consommation de mémoire.
Pour en savoir plus, consultez le guide de journalisation.
Débogage et profilage
Nous vous recommandons de désactiver les outils de débogage et de profilage, car ils entraînent généralement un surcoût en temps d'exécution.
Précharger
Depuis PHP 7.4, le préchargement OPcache peut être utilisé pour précharger des scripts en mémoire, ce qui va plus loin que le cache standard.
Un script doit être conçu pour tirer parti de cette fonctionnalité, mais la bibliothèque cliente PHP ne le fait pas, car il n'existe aucun moyen générique d'implémenter le préchargement de l'OPcache, et le compromis entre l'utilisation de la mémoire et le gain de performances est très spécifique à un projet et à une exécution donnés.