Das Google Cloud Search SDK enthält verschiedene von Google bereitgestellte Parameter, die von allen Connectors verwendet werden. Zu wissen, wie diese Einstellungen optimiert werden, die Indexierung von Daten. In diesem Leitfaden werden einige Probleme aufgeführt, während der Indexierung angezeigt werden kann, und die Einstellungen, mit denen das Problem behoben wird.
Niedriger Indexierungsdurchsatz für FullTraversalConnector
In der folgenden Tabelle sind die Konfigurationseinstellungen zur Verbesserung des Durchsatzes für einen FullTraversalConnector
| 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 der Konfigurationsdatei finden Sie unter Von Google bereitgestellte Konfigurationsparameter
Niedriger Indexierungsdurchsatz für ListTraversalConnector
Standardmäßig verwendet ein Connector, der den ListTraversalConnnector implementiert, einen
Single Traverser verwenden, um Ihre Elemente zu indexieren. Um den Indexierungsdurchsatz zu erhöhen, können Sie
Erstellen Sie mehrere Durchläufe, die jeweils eine eigene Konfiguration haben und sich auf bestimmte
Artikelstatus (NEW_ITEM, MODIFIED usw.). In der folgenden Tabelle sehen Sie
Konfigurationseinstellungen, um den Durchsatz zu verbessern:
| 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 der Konfigurationsdatei finden Sie unter Von Google bereitgestellte Konfigurationsparameter
SDK-Zeitüberschreitungen oder -Unterbrechungen beim Hochladen großer Dateien
Wenn beim Hochladen großer Dateien Zeitüberschreitungen oder Unterbrechungen durch das SDK auftreten,
ein größeres Zeitlimit mit
traverser.timeout=s
(s = Anzahl der Sekunden). Dieser Wert gibt an, wie lange
müssen Threads
ein Element verarbeiten. Das standardmäßige Zeitlimit im SDK beträgt 60 Sekunden
für Traverser-Threads. Wenn Sie einzelne API-Anfragen
können Sie mit den folgenden Methoden die Werte für die Zeitüberschreitung bei Anfragen 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. |