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, lässt sich die Indexierung von Daten erheblich optimieren. In diesem Leitfaden werden verschiedene Probleme aufgeführt, die bei der Indexierung auftreten können, sowie die Einstellungen, mit denen sie behoben werden.
Der Indexierungsdurchsatz ist für FullTraversalConnector niedrig
In der folgenden Tabelle sind die Konfigurationseinstellungen aufgeführt, mit denen der Durchsatz für einen FullTraversalConnector verbessert werden kann:
| Einstellung | Beschreibung | Standard | Zu testende Konfigurationsänderung |
|---|---|---|---|
traverse.partitionSize |
Die Anzahl der ApiOperation(), die in Batches verarbeitet werden, bevor weitere APIOperation() abgerufen werden. Das SDK wartet, bis die aktuelle Partition verarbeitet wurde, bevor weitere Elemente abgerufen werden. Diese Einstellung hängt vom verfügbaren Arbeitsspeicher ab. Kleinere Partitionsgrößen wie 50 oder 100 erfordern weniger Arbeitsspeicher, aber es dauert länger, bis das SDK die Daten verarbeitet. |
50 | Wenn Sie viel Arbeitsspeicher haben, erhöhen Sie partitionSize auf mindestens 1.000. |
batch.batchSize |
Die Anzahl der Anfragen, die in einem Batch zusammengefasst werden. Nach Abschluss der Partitionierung wartet das SDK, bis alle Batchanfragen aus der Partition verarbeitet wurden. Bei größeren Batches dauert es länger. | 10 | Versuchen Sie, die Batchgröße zu verringern. |
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 partititionSize beispielsweise 1.000 und batchSize 5 ist, sollte maxActiveBatches 250 sein. Die zusätzlichen 50 sind ein Puffer für Wiederholungsanfragen. Durch diese Erhöhung kann der Connector alle Anfragen ohne Blockierung in einem Batch senden. |
traverse.threadPoolSize |
Anzahl der Threads, die der Connector erstellt, um eine parallele Verarbeitung zu ermöglichen. Ein einzelner Iterator ruft Vorgänge (in der Regel RepositoryDoc Objekte) nacheinander ab, die API-Aufrufe werden jedoch parallel mit threadPoolSize Threads verarbeitet. In jedem Thread wird jeweils ein Element verarbeitet. Bei der Standardeinstellung von 50 werden maximal 50 Elemente gleichzeitig verarbeitet. Die Verarbeitung eines einzelnen Elements dauert etwa 4 Sekunden (einschließlich der Indexierungsanfrage). |
50 | Versuchen Sie, threadPoolSize um ein Vielfaches von 10 zu erhöhen. |
Mit der Methode setRequestMode() kannst du den API-Anfragemodus ändern (ASYNCHRONOUS oder SYNCHRONOUS).
Weitere Informationen zu Konfigurationsdateiparametern finden Sie in diesem Artikel.
Der Indexierungsdurchsatz ist für ListTraversalConnector niedrig
Standardmäßig verwendet ein Connector, der den ListTraversalConnector implementiert, einen einzelnen Durchsucher, um Ihre Elemente zu indexieren. Um den Indexierungsdurchsatz zu erhöhen, können Sie mehrere Durchläufe mit jeweils einer eigenen Konfiguration erstellen, die sich auf bestimmte Artikelstatus (NEW_ITEM, MODIFIED usw.) konzentrieren. In der folgenden Tabelle sind Konfigurationseinstellungen aufgeführt, mit denen Sie den Durchsatz verbessern können:
| Einstellung | Beschreibung | Standard | Zu testende Konfigurationsänderung |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Erstellt eine oder mehrere einzelne Traversen, wobei t1, t2, t3, ... der eindeutige Name der einzelnen Traversen ist. Jeder benannte Durchschreiter hat eigene Einstellungen, die anhand des eindeutigen Namens des Durchschreiters identifiziert werden, z. B. traversers.t1.hostload und traversers.t2.hostload. | Ein Traverser | Mit dieser Einstellung können Sie zusätzliche Durchsuchern hinzufügen. |
traversers.t1.hostload = n | Gibt die Anzahl der Threads (n) an, die zum gleichzeitigen Indexieren von Elementen verwendet werden sollen. | 5 | Passen Sie n an die gewünschte Auslastung Ihres Repositories an. Beginnen Sie mit Werten von 10 oder höher. |
schedule.pollQueueIntervalSecs = s | Gibt die Anzahl der Sekunden an, s, die gewartet werden soll, bevor eine weitere Abfrage erfolgt . Der Content-Connector führt weiterhin Umfragen durch, solange die API Elemente in der Umfrageantwort zurückgibt. Wenn die Antwort der Umfrage 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, wird der Durchschreiter t1 angewiesen, nur Elemente mit diesen Status zu indexieren. | Ein Durchschreiter prüft alle Status | Testen Sie, ob verschiedene Traverser nach verschiedenen Status fragen. |
Weitere Informationen zu Konfigurationsdateiparametern finden Sie in diesem Artikel.
SDK-Zeitüberschreitungen oder Unterbrechungen beim Hochladen großer Dateien
Wenn beim Hochladen großer Dateien ein SDK-Zeitlimit auftritt oder Unterbrechungen auftreten, geben Sie mit traverser.timeout=s ein größeres Zeitlimit an (s = Anzahl der Sekunden). Dieser Wert gibt an, wie lange Worker-Threads für die Verarbeitung eines Elements benötigen. Das Standardzeitlimit im SDK beträgt 60 Sekunden für Traverser-Threads. Wenn einzelne API-Anfragen ein Zeitlimit erreichen, können Sie die Zeitüberschreitung mit den folgenden Methoden verlängern:
| Parameter „Zeitüberschreitung bei Anfrage“ | Beschreibung | Standard |
|---|---|---|
indexingService.connectTimeoutSeconds |
Zeitüberschreitung bei der Verbindung für Indexing API-Anfragen. | 120 Sekunden. |
indexingService.readTimeoutSeconds |
Lesezeitlimit für Indexing API-Anfragen. | 120 Sekunden. |