Google Cloud Search SDK には、すべてのコネクタで使用される Google 提供構成パラメータが複数含まれています。これらの設定を調整する方法を知っていれば データのインデックス登録を大幅に効率化できます。このガイドでは、Google Cloud で およびその解決に使用される設定が表示されます。
FullTraversalConnector のインデックス登録のスループットが低い
次の表に、サービスのスループットを向上させるための構成設定を示します。 FullTraversalConnector:
| 設定 | 説明 | デフォルト | 試行する構成変更 |
|---|---|---|---|
traverse.partitionSize |
追加の APIOperation() を取得する前にバッチで処理される ApiOperation() の数。SDK は、追加のアイテムを取得する前に、現在のパーティションが処理されるまで待機します。この設定は、使用可能なメモリの量に依存します。50 や 100 などのようにパーティション サイズを小さくすると、必要なメモリは少なくなりますが、SDK の代わりに、より長く待機する必要があります。 |
50 | 使用可能なメモリが多い場合は、partitionSize を 1, 000 以上に増やしてみてください。 |
batch.batchSize |
バッチにまとめられるリクエストの数。パーティショニングの最後に、SDK は、バッチにまとめられたすべてのリクエストがパーティションから処理されるまで待機します。バッチが大きければ大きいほど、待機時間が長くなります。 | 10 | バッチサイズを小さくしてみてください。 |
batch.maxActiveBatches |
同時に実行することが許容されるバッチの数。 | 20 | batchSize を下げる場合は、次の式に従って maxActiveBatches の優先度を上げる必要があります。maxActiveBatches = (partitionSize / batchSize）+ 50 になります。たとえば、partititionSize が 1000 で batchSize が 5 の場合、maxActiveBatches は 250 になります。余分な 50 は、再試行リクエストのためのバッファーです。この増加により、コネクタはブロックせずにすべてのリクエストをバッチにまとめることができます。 |
traverse.threadPoolSize |
並列処理を可能にするためにコネクタが作成するスレッドの数。1 つのイテレータがオペレーション（通常は RepositoryDoc オブジェクト）を順次取得しますが、API 呼び出しは threadPoolSize 数のスレッドを使用して並列に処理します。各スレッドでは一度に 1 つのアイテムが処理されます。デフォルトの 50 では、最大 50 個のアイテムのみが同時に処理され、個々のアイテム（インデックス登録リクエストを含む）の処理には約 4 秒かかります。 |
50 | threadPoolSize を 10 の倍数に増やしてみてください。 |
最後に、setRequestMode() メソッドを使用して API リクエスト モード（ASYNCHRONOUS または SYNCHRONOUS）を変更することを検討してください。
構成ファイルのパラメータについて詳しくは、このモジュールの Google 提供の構成パラメータ。
ListTraversalConnector のインデックス登録のスループットが低い
デフォルトでは、ListTraversalConnnector を実装するコネクタは
単一走査を使用してアイテムをインデックス登録します。インデックス登録のスループットを向上させるには、
特定のタスクに重点を置いた独自の構成を持つ複数の走査を
アイテムのステータス（NEW_ITEM、MODIFIED など）。次の表に、
次のように構成してスループットを向上させます。
| 設定 | 説明 | デフォルト | 試行する構成変更 |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | 1 つ以上の個々の走査を作成します。t1, t2, t3, ... はそれぞれの一意の名前です。名前付きの各走査には、traversers.t1.hostload や traversers.t2.hostload など、走査の一意の名前で識別される独自の設定セットがあります。 | 1 つの走査 | この設定を使用して、走査を追加します。 |
traversers.t1.hostload = n | アイテムを同時にインデックスに登録するために使用するスレッド数 n を指定します。 | 5 | リポジトリにかかる負荷に基づいて、n をチューニングしてテストします。10 以上の値から始めます。 |
schedule.pollQueueIntervalSecs = s | 再ポーリングするまで待機する秒数（s）を指定します。API がポーリング レスポンスでアイテムを返す限り、コンテンツ コネクタはアイテムのポーリングを続行します。アンケートの回答が空の場合、コネクタは s 秒待ってから再試行します。この設定は、ListingConnector によってのみ使用されます。 | 10 | 1 に下げてみてください。 |
traverser.t1.pollRequest.statuses = status1, status2, … | インデックス登録するアイテムのステータス（status1、status2、…）を指定します。たとえば、status1 を NEW_ITEM に、status2 を MODIFIED に設定すると、走査 t1 に対し、これらのステータスのアイテムのみをインデックス登録するよう指示します。 | 1 つの走査がすべてのステータスをチェックします。 | さまざまな走査がさまざまなステータスをポーリングするようにしてみてください。 |
構成ファイルのパラメータについて詳しくは、このモジュールの Google 提供の構成パラメータ。
大きいファイルのアップロード中に SDK のタイムアウトや割り込みが発生する
大きなファイルのアップロード中に SDK のタイムアウトや中断が発生した場合は、
タイムアウトまでの時間を長くするには、
traverser.timeout=s
（s = 秒数）。この値は、ワーカーの
1 つのアイテムを処理する必要がありますSDK のデフォルトのタイムアウトは 60 秒です
トラバーサー スレッドのためのものです。また、個別の API リクエストが発生した場合、
次のメソッドでリクエストのタイムアウト値を増やします。
| リクエスト タイムアウトのパラメータ | 説明 | デフォルト |
|---|---|---|
indexingService.connectTimeoutSeconds |
インデックス登録 API リクエストの接続タイムアウト。 | 120 秒 |
indexingService.readTimeoutSeconds |
インデックス登録 API リクエストの読み取りタイムアウト。 | 120 秒 |