Pakiet SDK Google Cloud Search zawiera kilka parametrów konfiguracyjnych dostarczanych przez Google, które są używane przez wszystkie oprogramowanie sprzęgające. Wiedza o tym, jak dostosować te ustawienia, może znacznie uprościć indeksowanie danych. W tym przewodniku znajdziesz kilka problemów, które mogą pojawić się podczas indeksowania, wraz z ustawieniami użytymi do ich rozwiązania.
Niska przepustowość indeksowania w przypadku rozwiązania FullTraversalConnector
W tabeli poniżej znajdziesz ustawienia konfiguracji, które pozwalają zwiększyć przepustowość na FullTraversalConnector:
| lokalizacji, | Opis | Domyślne | Zmiana konfiguracji na próbę |
|---|---|---|---|
traverse.partitionSize |
Liczba operacji ApiOperation() do przetworzenia partiami przed pobraniem dodatkowych APIOperation(). Zanim pobierzesz dodatkowe elementy, pakiet SDK czeka na przetworzenie bieżącej partycji. To ustawienie zależy od ilości dostępnej pamięci. Mniejsze partycje, takie jak 50 lub 100, wymagają mniej pamięci, ale wymagają więcej czasu na obsługę pakietu SDK. |
50 | Jeśli masz dużo dostępnej pamięci, zwiększ partitionSize do 1000 lub więcej. |
batch.batchSize |
Liczba żądań zgrupowanych. Na końcu partycjonowania SDK czeka na przetworzenie wszystkich zbiorczych żądań z partycji. Większe partie wymagają dłuższego oczekiwania. | 10 | Spróbuj zmniejszyć rozmiar wsadu. |
batch.maxActiveBatches |
Liczba dozwolonych równoczesnych zadań wsadów. | 20 | Jeśli zmniejszysz wartość batchSize, musisz przesunąć wartość maxActiveBatches zgodnie z tym wzorem: maxActiveBatches = (partitionSize / batchSize) + 50. Jeśli na przykład partititionSize to 1000, a batchSize to 5, maxActiveBatches powinien mieć wartość 250. Dodatkowe 50 to bufor dla ponownych żądań. Dzięki temu oprogramowanie sprzęgające może grupować wszystkie żądania bez blokowania. |
traverse.threadPoolSize |
Liczba wątków tworzonych przez oprogramowanie sprzęgające, aby umożliwić równoległe przetwarzanie. Pojedynczy iterator pobiera operacje (zwykle RepositoryDoc obiektów), ale wywołania interfejsu API są przetwarzane równolegle z użyciem threadPoolSize wątków. Każdy wątek przetwarza 1 element naraz. Przy domyślnych wartości 50 jednocześnie przetwarzanych jest maksymalnie 50 elementów, a przetworzenie pojedynczego elementu (wraz z prośbą o zindeksowanie) trwa około 4 sekund. |
50 | Spróbuj zwiększyć threadPoolSize przez wielokrotność 10. |
Na koniec rozważ użycie metody setRequestMode(), by zmienić tryb żądania do interfejsu API (ASYNCHRONOUS lub SYNCHRONOUS).
Więcej informacji o parametrach pliku konfiguracji znajdziesz w artykule Parametry konfiguracji dostarczane przez Google.
Przepustowość indeksowania w przypadku ListTraversalConnector jest niska
Domyślnie oprogramowanie sprzęgające, które implementuje element ListTraversalConnnector, używa do indeksowania elementów pojedynczego trawersu. Aby zwiększyć szybkość indeksowania, możesz utworzyć wiele punktów przemierzania, każdy z osobną konfiguracją skupiającą się na konkretnych stanach elementów (NEW_ITEM, MODIFIED itd.). W tej tabeli znajdziesz ustawienia konfiguracji, które pomogą Ci zwiększyć przepustowość:
| lokalizacji, | Opis | Domyślne | Zmiana konfiguracji na próbę |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Tworzy co najmniej 1 trawers, gdzie t1, t2, t3, ... to unikalna nazwa każdego z nich. Każdy nazywany trawerterem ma własny zestaw ustawień, które są określane za pomocą jego niepowtarzalnej nazwy, np. traversers.t1.hostload i traversers.t2.hostload. | 1 trawerter | Użyj tego ustawienia, aby dodać więcej trawersów |
traversers.t1.hostload = n | Określa liczbę wątków (n), która ma być używana do jednoczesnego indeksowania elementów. | 5 | Eksperymentuj z dostrajaniem n w zależności od tego, ile obciążenia chcesz umieścić w repozytorium. Zacznij od wartości 10 lub więcej. |
schedule.pollQueueIntervalSecs = s | Określa czas oczekiwania (w sekundach) s przed ponownym przeprowadzeniem ankiety . Oprogramowanie sprzęgające treści będzie nadal odpytywać elementy, dopóki interfejs API zwróci elementy w odpowiedzi na ankietę. Gdy odpowiedź na zapytanie jest pusta, oprogramowanie sprzęgające czeka s s przed ponowną próbą. To ustawienie jest używane tylko przez ListingConnector | 10 | Spróbuj obniżyć go do 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Określa stany (status1, status2, …) elementów do zindeksowania. Na przykład ustawienie zasady status1 na NEW_ITEM i status2 na MODIFIED instruuje przemierzającego t1, aby indeksować tylko elementy o tych stanach. | 1 trawerter sprawdza wszystkie stany | Eksperymentuj z wyborem różnych osób pokonujących różne statusy. |
Więcej informacji o parametrach pliku konfiguracji znajdziesz w artykule Parametry konfiguracji dostarczane przez Google.
Przekroczenie limitu czasu oczekiwania pakietu SDK lub jego przerwanie podczas przesyłania dużych plików
Jeśli podczas przesyłania dużych plików wystąpi przekroczenie limitu czasu lub przerwy w pakiecie SDK, określ dłuższy limit czasu za pomocą traverser.timeout=s (gdzie s = liczba sekund). Ta wartość określa, jak długo wątki robocze muszą przetworzyć element. Domyślny limit czasu w pakiecie SDK to 60 sekund dla wątków przemierzania. Dodatkowo, jeśli czas oczekiwania na pojedyncze żądania do interfejsu API się wyczerpuje, użyj tych metod, aby zwiększyć limit czasu żądania:
| Parametr limitu czasu żądania | Opis | Domyślne |
|---|---|---|
indexingService.connectTimeoutSeconds |
Upłynął limit czasu połączenia na potrzeby żądań do interfejsu API indeksowania. | 120 sekund. |
indexingService.readTimeoutSeconds |
Limit czasu odczytu żądań do interfejsu API indeksowania. | 120 sekund. |