Das Google Cloud Search SDK enthält mehrere von Google bereitgestellte Konfigurationsparameter, die von allen Connectors verwendet werden. Zu wissen, wie diese Einstellungen optimiert werden, kann die Indexierung von Daten erheblich optimieren. In diesem Leitfaden werden verschiedene Probleme, die bei der Indexierung auftreten können, und die Einstellungen zu deren Behebung aufgeführt.
Niedriger Indexierungsdurchsatz für FullTraversalConnector
In der folgenden Tabelle sind die 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 von ApiOperation(), die in Batches verarbeitet werden sollen, bevor zusätzliche 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, dafür aber mehr Wartezeiten durch das SDK. |
50 | Wenn Sie viel Arbeitsspeicher haben, versuchen Sie, partitionSize auf mindestens 1.000 zu erhöhen. |
batch.batchSize |
Die Anzahl der zusammengefassten Anfragen. Am Ende der Partitionierung wartet das SDK, bis alle Batchanfragen von der Partition verarbeitet wurden. Größere Batches erfordern eine längere Wartezeit. | 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äß der folgenden Formel anheben: maxActiveBatches = (partitionSize / batchSize) + 50. Beispiel: Wenn Ihre partititionSize 1.000 und Ihre batchSize 5 ist, sollte Ihre maxActiveBatches 250 sein. Die zusätzlichen 50 sind ein Puffer für Wiederholungsanfragen. Durch diese Erhöhung kann der Connector alle Anfragen in Batches zusammenfassen, ohne sie zu blockieren. |
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, aber die API-Aufrufe werden mit einer Anzahl von threadPoolSize Threads parallel verarbeitet. In jedem Thread wird jeweils ein Element verarbeitet. Mit der Standardeinstellung „50“ werden maximal 50 Elemente gleichzeitig verarbeitet. Die Verarbeitung eines einzelnen Elements (einschließlich der Indexierungsanfrage) dauert ungefähr 4 Sekunden. |
50 | Versuchen Sie, threadPoolSize um ein Vielfaches von 10 zu erhöhen. |
Abschließend können Sie die Methode setRequestMode() verwenden, um den API-Anfragemodus (entweder ASYNCHRONOUS oder SYNCHRONOUS) zu ändern.
Weitere Informationen zu den Parametern für Konfigurationsdateien finden Sie unter Von Google bereitgestellte Konfigurationsparameter.
Niedriger Indexierungsdurchsatz für ListTraversalConnector
Standardmäßig verwendet ein Connector, der ListTraversalConnnector implementiert, einen einzelnen Durchlauf, um Ihre Elemente zu indexieren. Sie können mehrere Durchläufe erstellen, die jeweils eine eigene Konfiguration haben und sich auf bestimmte Elementstatus (NEW_ITEM, MODIFIED usw.) konzentrieren, um den Indexierungsdurchsatz zu erhöhen. In der folgenden Tabelle sind die Konfigurationseinstellungen zur Verbesserung des Durchsatzes aufgeführt:
| Einstellung | Beschreibung | Standard | Konfigurationsänderung zum Ausprobieren |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Erstellt einen oder mehrere einzelne Durchläufe, wobei t1, t2, t3, ... der eindeutige Name jedes Durchlaufs ist. Jeder Benannte Durchlaufer hat seine eigenen Einstellungen, die durch den eindeutigen Namen des Durchläufers identifiziert werden, z. B. traversers.t1.hostload und traversers.t2.hostload. | Ein Durchlaufer | Mit dieser Einstellung können Sie zusätzliche Durchläufer hinzufügen |
traversers.t1.hostload = n | Gibt die Anzahl der Threads (n) an, die zum gleichzeitigen Indexieren von Elementen verwendet werden sollen. | 5 | Experimentieren Sie mit der Abstimmung von n auf der Grundlage der Last, die Sie für Ihr Repository einsetzen möchten. Beginnen Sie mit Werten ab 10. |
schedule.pollQueueIntervalSecs = s | Gibt an, wie viele Sekunden vor einem erneuten Abruf gewartet werden soll (s). Der Inhalts-Connector fragt weiterhin Elemente ab, solange die API Elemente in der Abfrageantwort zurückgibt. Wenn die Abfrageantwort leer ist, wartet der Connector s Sekunden, bevor er es noch einmal versucht. Diese Einstellung wird nur vom ListingConnector verwendet | 10 | Senken Sie den Wert auf 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Gibt die Status (status1, status2, …) der zu indexierenden Elemente an. Wenn Sie beispielsweise status1 auf NEW_ITEM und status2 auf MODIFIED setzen, weisen Sie den Traverser t1 an, nur Elemente mit diesem Status zu indexieren. | Ein Traverser prüft alle Status | Experimentieren Sie mit unterschiedlichen Durchläufern, die verschiedene Status abfragen. |
Weitere Informationen zu den Parametern für Konfigurationsdateien finden Sie unter Von Google bereitgestellte Konfigurationsparameter.
SDK-Zeitüberschreitungen oder -Unterbrechungen beim Hochladen großer Dateien
Wenn beim Hochladen großer Dateien SDK-Zeitüberschreitungen 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 haben. Das Standardzeitlimit im SDK beträgt für Durchlauf-Threads 60 Sekunden. Wenn es zu einer Zeitüberschreitung bei einzelnen API-Anfragen kommt, können Sie außerdem die folgenden Methoden verwenden, um die Werte für die Zeitüberschreitung bei Anfragen zu erhöhen:
| Zeitüberschreitungsparameter für Anfrage | Beschreibung | Standard |
|---|---|---|
indexingService.connectTimeoutSeconds |
Verbindungszeitlimit für die Indexierung von API-Anfragen. | 120 Sekunden. |
indexingService.readTimeoutSeconds |
Zeitüberschreitung beim Lesen von API-Anfragen zur Indexierung. | 120 Sekunden. |