The Google Ads .NET client library simplifies your app's interactions with the Google Ads API, with minimal configuration on your part. However, the overall performance highly depends on how the library is used and integrated with your app.
This guide covers performance optimizations that are specific to .NET apps, and complements the best practices that are generally applicable to the Google Ads API.
Reuse GoogleAdsClient whenever possible
GoogleAdsClient
represents a user's session when making API calls. It provides
optimizations such as:
- Caching the gRPC channels used by API services. This reduces the setup time when making initial API calls.
- Reusing access tokens when possible. This reduces the number of round trips that the Google Ads .NET client library has to perform to refresh access tokens.
Use access tokens from a manager level account when possible
- If you have an access token issued at a manager account level, you can use it
to make API calls against all Google Ads client accounts under that account
hierarchy. When combined with reusing
GoogleAdsClient
instances, this can further reduce the number of round trips the client library has to perform to refresh access tokens.
Use SearchStream instead of Search whenever possible
While GoogleAdsService.Search
can
send multiple paginated requests to download the entire report,
GoogleAdsService.SearchStream
sends a single request and initiates a persistent connection with the Google Ads API
regardless of the report size. By eliminating the round-trip network time
required to request each individual page of a Search
response, depending on
your app, SearchStream
might offer improved performance over paging. See
Search versus
SearchStream to learn
more about this optimization.
Manually manage access token refreshes
In certain environments such as Google Cloud
Functions, it might not be feasible to reuse
GoogleAdsClient
instances. Such environments can come with their own best
practices to persist and reuse data. In such cases, you can extend the
GoogleAdsConfig
class to perform your own access token refreshes as follows.
// Create your own config class by extending the GoogleAdsConfig class.
class MyGoogleAdsConfig : GoogleAdsConfig
{
public MyGoogleAdsConfig() : base()
{
// Disable the library's in-built channel caching mechanism.
this.UseChannelCache = false;
}
protected override ICredential CreateCredentials()
{
// TODO: Create your own ICredentials object here. You may refer to the
// default implementation of GoogleAdsConfig::CreateCreateCredentials
// for an example.
}
}
// Use your own config class when initializing the GoogleAdsClient instance.
MyGoogleAdsConfig myconfig = new MyGoogleAdsConfig();
GoogleAdsClient client = new GoogleAdsClient(myconfig);
Compile for release build
Make sure you compile your app using Release configuration when deploying to the server. When using the Debug configuration, your app compiles with full symbolic debug information and no optimization.
Profile your app
Profile your app both for CPU and memory usage to identify performance bottlenecks. Visual Studio provides Diagnostic tools to help profile your app. There are also other commercial profiling tools that are available.
Use async methods
Asynchronous programming using the async-await paradigm helps avoid performance bottlenecks and enhance the overall responsiveness of your app. The Google Ads .NET library generates async methods for all services and RPC methods.
Async methods cancellation
You can use the callSettings
parameter to pass a
CancellationToken
to async methods:
CancellationTokenSource cancellationTokenSource = new CancellationTokenSource();
cancellationTokenSource.CancelAfter(3000);
CallSettings callSettings = CallSettings.FromCancellationToken(cancellationTokenSource.Token);
string query = "SELECT campaign.name FROM campaign";
var request = new SearchGoogleAdsStreamRequest()
{
CustomerId = customerId.ToString(),
Query = query,
};
GoogleAdsServiceClient googleAdsService = client.GetService(
Services.V18.GoogleAdsService);
googleAdsService.SearchStream(request,
delegate (SearchGoogleAdsStreamResponse resp)
{
foreach (GoogleAdsRow googleAdsRow in resp.Results)
{
// Process the row.
}
}, callSettings
);
Turn off logging when you can
The Google Ads .NET library turns off logging by default and uses a lazy logging approach which gives your app better performance. If you turn on logging, make sure you turn it off in the production environment. If you need to monitor for specific failing requests in production, you can do one or more of the following steps without adversely affecting your app's performance:
- Turn on just the summary logs.
- Set the full logs to
ERROR
level. - Save the request ID for specific requests of interest that you can share with the support channels.
See the logging guide to learn more.
Decide whether to use the SearchStream or Search method
The Google Ads API provides two main ways to retrieve objects: the Search
method
(which uses pagination) and SearchStream
(which uses streaming).
SearchStream
provides better performance over Search
, but there are
scenarios where Search
is preferred.
See the streaming reports guide to learn more about the two methods.
Use ReadyToRun option
.NET Core 3.1 adds support for precompiling your binaries to a specific platform
and architecture by specifying a PublishReadyToRun
setting to true
, and
then publishing the binary by specifying a valid RuntimeIdentifier
when
publishing. See the guide on the ReadyToRun
feature to learn
more.
Use TieredCompilation
TieredCompilation
allows .NET to identify hotspots and improve its
performance. Tiered compilation works better with the ReadyToRun
option since
it can use the pre-generated image when available. See the guide on
TieredCompilation
to learn more.
Fine-tune your garbage collection (GC)
.NET provides two general profiles for garbage collection (GC): a workstation profile and a server profile. These two profiles have differing performance tradeoffs. Apps using the Google Ads .NET library tend to perform better when running in a server profile. You can benefit from fine tuning the following GC settings.
Server garbage collection: Server garbage collection allows .NET runtime to give better performance to a Google Ads API app by operating on multiple threads. See this guide for more details. You can turn on server garbage collection by adding the following lines to your app's
.csproj
file.<PropertyGroup> <ServerGarbageCollection>true</ServerGarbageCollection> </PropertyGroup>
Concurrent garbage collection: You can turn on concurrent garbage collection to give .NET GC a dedicated thread for garbage collection in generation 2. This setting can be useful when processing reports with large sizes. You can turn on concurrent garbage collection by adding the following lines to your app's
.csproj
file.<PropertyGroup> <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection> </PropertyGroup>
Retain VM garbage collection: The
RetainVMGarbageCollection
setting configures whether segments of virtual memory that should be deleted are put on a standby list for future use, or are released back to the operating system (OS). You can turn on virtual memory retention by adding the following lines to your app.<PropertyGroup> <RetainVMGarbageCollection>true</RetainVMGarbageCollection> </PropertyGroup>
You can fine tune your GC by settling for a setup that is between
a workstation and a server. All the relevant
settings
are specified in your .NET Core app's runtimeconfig.json
file, an environment
variable, or your .NET SDK app’s App.config
.