Performance

The PHP client library eases interactions with the Google Ads API with minimal configuration on your part. However, performance highly depends on how the library is used and integrated.

Most of these best practices are applicable to all languages. This guide goes through the ones that are specific to PHP.

Protobuf implementation

Protobuf is used by gRPC and the Google Ads API for request and response messages. Two implementations are available, though the one written in C has the better performance.

See the Protobuf guide for more information.

Operation mode of the PHP interpreter

PHP is a versatile scripting language and has many operation modes depending on usage. PHP CGI (Common Gateway Interface) has a notable advantage because it can share resources between executions.

PHP version

It is good practice to regularly upgrade to a newer PHP version as it usually comes with better overall performance. List of supported PHP versions.

Unused Google Ads API versions

All versions of the client library support multiple Google Ads API versions. For each version of the Google Ads API supported by the client library, there are dedicated packages for the version.

The packages dedicated to versions of the Google Ads API that are not used can be safely removed from the client library. Because it can be useful to speed up execution or reduce memory footprint, the client library provides utilities to do it programmatically.

Warning: This removes files, which cannot easily be undone.

Example

Suppose that you're implementing the client library that's using only the latest API version: v11, and you want to remove support for the unused API versions: v10 and v9.

In the composer.json file of the project, define a Composer script (named remove-google-ads-api-version-support) that leverages the utility provided by the client library, in the class ApiVersionSupport:

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

Then, use the Composer script with the version numbers as parameters and print some status messages:

# 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 v9 and v10 of the Google Ads API.
echo "# Removing support..."
composer run-script remove-google-ads-api-version-support -- 9 10

# 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

The sample execution output below indicates a file size reduction of 50M and the only remaining supported version is V11:

# Supported Google Ads API versions:
V9
V10
V11
# Vendor folder size:
110M    ./vendor
# Removing support...
> Google\Ads\GoogleAds\Util\ApiVersionSupport::remove
Removing support for the version 9 of Google Ads API...
Done
Removing support for the version 10 of Google Ads API...
Done
# Supported Google Ads API versions:
V11
# Vendor folder size:
60M     ./vendor

Note: If you're developing on the client library project itself, a Composer script is already defined for your convenience: remove-api-version-support.

Development versus production

PHP is an interpreted language in that it first compiles instructions before executing them. This is usually advantageous since during development time, sources often change while execution time is not that crucial. However, the opposite is true at production time as stability and performance become the main concerns.

Cache

Caching is common and highly recommended because it both improves performance and increases stability by storing precompiled script instructions.

OPcache is the most commonly used solution and is available by default.

Autoload

Autoload is common because it both improves performance and increases stability by loading precompiled information about classes.

The PHP client library conforms to PSR-4 for autoloading and provides the definition as part of the composer.json file. Dedicated options of Composer, such as --optimize-autoloader or --classmap-authoritative for example, can then be used out of the box.

Logging

Setting loggers to a high level like ERROR can help reduce execution time overhead and memory consumption.

See the Logging guide for more information.

Debugging & profiling

We recommend disabling debugger and profiler tools as they usually come with some execution time overhead.

Preload

Since PHP 7.4, OPcache preloading can be used to preload scripts in memory, going one step further than regular caching.

A script has to be designed to take advantage of this feature, but the PHP client library doesn't since there is no generic way of implementing OPcache preloading, and the trade-off between memory usage and performance gain is highly specific to a given project and execution.