このページは Cloud Translation API によって翻訳されました。

コネクタ設定の調整

Google Cloud Search SDK には、すべてのコネクタで使用される Google 提供構成パラメータが複数含まれています。これらの設定を調整する方法を知っておくことで、データのインデックス登録を大幅に効率化できます。このガイドには、インデックス登録中に発生する可能性のあるいくつかの問題と、それらを解決するために使用される設定がリストされています。

FullTraversalConnector のインデックス登録のスループットが低い

次の表に、FullTraversalConnector のスループットを改善するための構成設定を示します。

設定	説明	デフォルト	試行する構成変更
`traverse.partitionSize`	追加の `APIOperation()` を取得する前にバッチで処理される `ApiOperation()` の数。SDK は、追加のアイテムを取得する前に、現在のパーティションが処理されるまで待機します。この設定は、使用可能なメモリの量に依存します。50 や 100 などのようにパーティションサイズを小さくすると、必要なメモリは少なくなりますが、SDK の代わりに、より長く待機する必要があります。	50	使用可能なメモリが多い場合は、`partitionSize` を 1000 以上に増やしてみてください。
`batch.batchSize`	バッチにまとめられるリクエストの数。パーティショニングの最後に、SDK は、バッチにまとめられたすべてのリクエストがパーティションから処理されるまで待機します。バッチが大きければ大きいほど、待機時間が長くなります。	10	バッチサイズを小さくしてみてください。
`batch.maxActiveBatches`	同時に実行することが許容されるバッチの数。	20	`batchSize` を小さくする場合は、次の式に従って `maxActiveBatches` をバンプする必要があります。 `maxActiveBatches = (partitionSize / batchSize`）+ 50。たとえば、`partititionSize` が 1000 で `batchSize` が 5 の場合、`maxActiveBatches` は 250 になります。余分な 50 は、再試行リクエストのためのバッファーです。この増加により、コネクタはブロックせずにすべてのリクエストをバッチにまとめることができます。
`traverse.threadPoolSize`	並列処理を可能にするためにコネクタが作成するスレッドの数。単一のイテレータはオペレーション（通常は `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 つの走査がすべてのステータスをチェックします。	さまざまな走査がさまざまなステータスをポーリングするようにしてみてください。