Google Ads .NET クライアント ライブラリを使用すると、アプリと Google Ads API のやり取りが簡素化され、ユーザー側の構成が最小限に抑えられます。ただし、全体的なパフォーマンスは、ライブラリの使用方法やアプリとの統合方法に大きく左右されます。
このガイドでは、.NET アプリに固有のパフォーマンス最適化について説明します。これは、Google Ads API に一般的に適用されるベスト プラクティスを補完するものです。
可能な限り GoogleAdsClient を再利用する
GoogleAdsClient は、API 呼び出しを行う際のユーザーのセッションを表します。次のような最適化が提供されます。
- API サービスで使用される gRPC チャネルをキャッシュに保存します。これにより、最初の API 呼び出しを行う際の設定時間が短縮されます。
- 可能な場合はアクセス トークンを再利用します。これにより、Google Ads .NET クライアント ライブラリがアクセス トークンを更新するために実行する必要があるラウンド トリップの数が減ります。
可能な場合は、MCC アカウントのアクセス トークンを使用する
MCC アカウント レベルで発行されたアクセス トークンがある場合は、そのアカウント階層内のすべての Google 広告クライアント アカウントに対して API 呼び出しを行うために使用できます。GoogleAdsClient インスタンスの再利用と組み合わせることで、クライアント ライブラリがアクセス トークンを更新するために実行する必要があるラウンド トリップの数をさらに減らすことができます。
可能な限り Search ではなく SearchStream を使用する
Google Ads API には、オブジェクトを取得する 2 つの主な方法（GoogleAdsService.Search（ページネーションを使用）と GoogleAdsService.SearchStream（ストリーミングを使用））があります。
Search は、レポート全体をダウンロードするために複数のページ分割されたリクエストを送信しますが、SearchStream は単一のリクエストを送信し、レポートのサイズに関係なく Google Ads API との永続的な接続を開始します。Search レスポンスの各ページをリクエストするために必要な往復ネットワーク時間を排除することで、SearchStream は一般的にページングよりもパフォーマンスが向上します。各方法を選択するタイミングについて詳しくは、ストリーミング レポート ガイドをご覧ください。
アクセス トークンの更新を手動で管理する
Google Cloud Functions などの特定のステートレス環境では、呼び出し間で GoogleAdsClient インスタンスを再利用することができない場合があります。このような環境には、データを永続化して再利用するための独自のベスト プラクティスがあります。
Google.Ads.GoogleAds v27.0.0 以降では、Credentials プロパティを使用して、事前構成済みの ICredential インスタンスを GoogleAdsConfig に直接挿入し、チャンネル キャッシュ（UseChannelCache = false）を無効にできます。
認証情報の作成をカスタム構成クラスにカプセル化する場合（または、以前のバージョンのライブラリを使用している場合）は、次のように GoogleAdsConfig クラスを拡張して、独自のアクセス トークン更新を実行できます。
// Create your own config class by extending the GoogleAdsConfig class.
class MyGoogleAdsConfig : GoogleAdsConfig
{
public MyGoogleAdsConfig() : base()
{
// Disable the library's built-in channel caching mechanism.
UseChannelCache = false;
}
protected override ICredential CreateCredentials()
{
// Create your own ICredential object here. You may refer to the
// default implementation of GoogleAdsConfig.CreateCredentials
// for an example.
}
}
// Use your own config class when initializing the GoogleAdsClient instance.
MyGoogleAdsConfig myConfig = new MyGoogleAdsConfig();
GoogleAdsClient client = new GoogleAdsClient(myConfig);
リリースビルド用にコンパイルする
サーバーにデプロイするときは、リリース構成を使用してアプリをコンパイルしてください。デバッグ構成を使用すると、アプリは完全なシンボリック デバッグ情報でコンパイルされ、コンパイラの最適化は行われません。
アプリのプロファイリングを行う
CPU とメモリの両方の使用量についてアプリをプロファイリングして、パフォーマンスのボトルネックを特定します。Visual Studio には、アプリのプロファイリングに役立つ診断ツールが用意されています。また、利用可能な商用プロファイリング ツールもあります。
非同期メソッドを使用する
async-await パラダイムを使用した非同期プログラミングは、パフォーマンスのボトルネックを回避し、アプリの全体的な応答性を高めるのに役立ちます。Google 広告 .NET ライブラリは、すべてのサービスと RPC メソッドに対して非同期メソッドを生成します。
非同期メソッドのキャンセル
callSettings パラメータを使用すると、SearchStreamAsync などの非同期メソッドに CancellationToken を渡すことができます。
using 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.V25.GoogleAdsService);
await googleAdsService.SearchStreamAsync(
request,
(SearchGoogleAdsStreamResponse resp) =>
{
foreach (GoogleAdsRow googleAdsRow in resp.Results)
{
// Process the row.
}
},
callSettings);
可能な場合はロギングをオフにする
Google 広告 .NET ライブラリでは、デフォルトでロギングが無効になり、アプリのパフォーマンスを向上させる遅延ロギング アプローチが使用されます。開発中にロギングを有効にした場合は、本番環境で無効にしてください。本番環境で特定のリクエストの失敗をモニタリングする必要がある場合は、アプリのパフォーマンスに悪影響を及ぼすことなく、次の手順を 1 つ以上実行できます。
- 要約ログのみをオンにします。
- 完全なログを
ERRORレベルに設定します。 - 特定の失敗したリクエストのリクエスト ID を保存して、サポート チャネルと共有できるようにします。
詳しくは、ロギング ガイドをご覧ください。
ReadyToRun オプションを使用する
最新の .NET では、PublishReadyToRun を true に設定して、バイナリを特定のプラットフォームとアーキテクチャに事前コンパイルし、有効な RuntimeIdentifier を指定してバイナリを公開できます。詳細については、ReadyToRun デプロイガイドをご覧ください。
TieredCompilation を使用する
TieredCompilation（.NET 8 などの最新の .NET バージョンでデフォルトで有効になっています）を使用すると、.NET でホットスポットを特定し、ランタイム パフォーマンスを向上させることができます。階層化コンパイルは、ReadyToRun との相性が優れています。これは、事前生成されたイメージを使用して高速起動を行い、ホットメソッドを完全な最適化で再コンパイルできるためです。詳しくは、TieredCompilation ガイドをご覧ください。
ガベージ コレクション（GC）を調整する
.NET には、ガベージ コレクション（GC）用のワークステーション プロファイルとサーバー プロファイルという 2 つの一般的なプロファイルがあります。この 2 つのプロファイルには、パフォーマンスのトレードオフが異なります。Google Ads .NET ライブラリを使用する専用サーバーアプリは、サーバー プロファイルで実行するとパフォーマンスが向上することがよくあります。
次の GC 設定をファインチューニングすると、メリットがあります。
サーバー ガベージ コレクション: サーバー ガベージ コレクションにより、.NET ランタイムは複数の GC ヒープとスレッドで動作することで、Google Ads API アプリに高いスループットを提供できます。詳細については、サーバー GC ガイドをご覧ください。アプリの
.csprojファイルに次の行を追加すると、サーバーのガベージ コレクションを有効にできます。<PropertyGroup> <ServerGarbageCollection>true</ServerGarbageCollection> </PropertyGroup>同時実行ガベージ コレクション: 同時実行ガベージ コレクションを有効にすると、.NET GC に世代 2 のガベージ コレクション専用のスレッドが提供されます。この設定は、大きなレポートを処理する際に役立ちます。アプリの
.csprojファイルに次の行を追加すると、同時ガベージ コレクションを有効にできます。<PropertyGroup> <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection> </PropertyGroup>VM のガベージ コレクションを保持する:
RetainVMGarbageCollection設定は、削除される仮想メモリのセグメントを将来の使用のためにスタンバイ リストに配置するか、オペレーティング システム（OS）に解放するかを構成します。アプリの.csprojファイルに次の行を追加すると、仮想メモリの保持を有効にできます。<PropertyGroup> <RetainVMGarbageCollection>true</RetainVMGarbageCollection> </PropertyGroup>
ワークステーションとサーバーの動作のバランスが取れた設定を選択することで、GC を微調整できます。関連する GC 設定はすべて、.NET アプリの runtimeconfig.json ファイル、環境変数、または App.config で指定できます。