Diese Seite wurde von der Cloud Translation API übersetzt.

Einstellungen für Connector anpassen

Das Google Cloud Search SDK enthält mehrere von Google bereitgestellte Konfigurationsparameter, die von allen Connectors verwendet werden. Wenn Sie wissen, wie Sie diese Einstellungen optimieren, können Sie die Indexierung von Daten erheblich beschleunigen. In dieser Anleitung werden verschiedene Probleme aufgeführt, die während der Indexierung auftreten können, sowie die Einstellungen, mit denen sie behoben werden können.

Der Indexierungsdurchsatz ist für FullTraversalConnector niedrig.

In der folgenden Tabelle sind Konfigurationseinstellungen aufgeführt, mit denen der Durchsatz für einen FullTraversalConnector verbessert werden kann:

Einstellung	Beschreibung	Standard	Konfigurationsänderung zum Ausprobieren
`traverse.partitionSize`	Die Anzahl der `ApiOperation()`, die in Batches verarbeitet werden sollen, bevor zusätzliche `APIOperation()` abgerufen werden. Das SDK wartet, bis die aktuelle Partition verarbeitet wurde, bevor zusätzliche Elemente abgerufen werden. Diese Einstellung hängt vom verfügbaren Arbeitsspeicher ab. Kleinere Partitionsgrößen wie 50 oder 100 erfordern weniger Arbeitsspeicher, aber das SDK muss länger warten.	50	Wenn Sie viel Arbeitsspeicher zur Verfügung haben, können Sie `partitionSize` auf 1.000 oder mehr erhöhen.
`batch.batchSize`	Die Anzahl der zusammengefassten Anfragen. Am Ende der Partitionierung wartet das SDK, bis alle Batchanfragen aus der Partition verarbeitet wurden. Bei größeren Batches müssen Sie länger warten.	10	Reduzieren Sie die Batchgröße.
`batch.maxActiveBatches`	Anzahl der zulässigen gleichzeitig ausgeführten Batches.	20	Wenn Sie `batchSize` senken, sollten Sie `maxActiveBatches` gemäß dieser Formel erhöhen: `maxActiveBatches = (partitionSize / batchSize`) + 50. Wenn Ihr `partititionSize` beispielsweise 1.000 und Ihr `batchSize` 5 ist, sollte Ihr `maxActiveBatches` 250 sein. Die zusätzlichen 50 Anfragen sind ein Puffer für Wiederholungsanfragen. Durch diese Erhöhung kann der Connector alle Anfragen ohne Blockierung in Batches verarbeiten.
`traverse.threadPoolSize`	Anzahl der Threads, die vom Connector für die parallele Verarbeitung erstellt werden. Mit einem einzelnen Iterator werden Vorgänge (in der Regel `RepositoryDoc`-Objekte) seriell abgerufen, die API-Aufrufe werden jedoch parallel mit `threadPoolSize` Threads verarbeitet. Jeder Thread verarbeitet jeweils ein Element. Bei der Standardeinstellung von 50 werden maximal 50 Elemente gleichzeitig verarbeitet. Die Verarbeitung eines einzelnen Elements (einschließlich der Indexierungsanfrage) dauert etwa 4 Sekunden.	50	Erhöhen Sie `threadPoolSize` um ein Vielfaches von 10.

Sie können auch die Methode setRequestMode() verwenden, um den API-Anfragemodus (entweder ASYNCHRONOUS oder SYNCHRONOUS) zu ändern.

Weitere Informationen zu den Parametern der Konfigurationsdatei finden Sie unter Von Google bereitgestellte Konfigurationsparameter.

Der Indexierungsdurchsatz ist für ListTraversalConnector niedrig

Standardmäßig verwendet ein Connector, der den ListTraversalConnector implementiert, einen einzelnen Traverser zum Indexieren Ihrer Elemente. Um den Indexierungsdurchsatz zu erhöhen, können Sie mehrere Traverser erstellen, die jeweils eine eigene Konfiguration haben, die sich auf bestimmte Elementstatus konzentriert (NEW_ITEM, MODIFIED usw.). In der folgenden Tabelle sind Konfigurationseinstellungen zur Verbesserung des Durchsatzes aufgeführt:

Einstellung	Beschreibung	Standard	Konfigurationsänderung zum Ausprobieren
`repository.traversers = t1, t2, t3, ...`	Erstellt einen oder mehrere einzelne Traverser, wobei `t1, t2, t3, ...` der eindeutige Name des jeweiligen Traversers ist. Jeder benannte Traverser hat eigene Einstellungen, die anhand des eindeutigen Namens des Traversers identifiziert werden, z. B. `traversers.t1.hostload` und `traversers.t2.hostload`.	Ein Traverser	Mit dieser Einstellung können Sie zusätzliche Traverser hinzufügen.
`traversers.t1.hostload = n`	Gibt die Anzahl der Threads (`n`) an, die zum gleichzeitigen Indexieren von Elementen verwendet werden sollen.	5	Sie können `n` anpassen, je nachdem, wie viel Last Sie auf Ihr Repository legen möchten. Beginnen Sie mit Werten von 10 oder höher.
`schedule.pollQueueIntervalSecs = s`	Gibt die Anzahl der Sekunden (`s`) an, die vor dem erneuten Abrufen gewartet werden soll . Der Content-Connector fragt weiterhin Elemente ab, solange die API Elemente in der Abfrageantwort zurückgibt. Wenn die Antwort auf den Poll leer ist, wartet der Connector `s` Sekunden, bevor er es noch einmal versucht. Diese Einstellung wird nur vom ListingConnector verwendet.	10	Versuchen Sie, den Wert auf 1 zu senken.
`traverser.t1.pollRequest.statuses = status1, status2, …`	Gibt die Status `status1`, `status2` und `…` der zu indexierenden Elemente an. Wenn Sie beispielsweise `status1` auf `NEW_ITEM` und `status2` auf `MODIFIED` festlegen, werden mit dem Traverser `t1` nur Elemente mit diesen Status indexiert.	Ein Traverser prüft alle Status.	Sie können verschiedene Traverser so konfigurieren, dass sie unterschiedliche Status abrufen.