Pakiet SDK Google Cloud Search zawiera kilka parametrów konfiguracji dostarczonych przez Google, które są używane przez wszystkie oprogramowania sprzęgające. Umiejętność dostosowania tych ustawień może znacznie usprawnić indeksowanie danych. W tym przewodniku wymieniono kilka problemów, które mogą wystąpić podczas indeksowania, oraz ustawienia, które pomogą je rozwiązać.
Przepustowość indeksowania jest niska w przypadku FullTraversalConnector
W tabeli poniżej znajdziesz ustawienia konfiguracji, które poprawiają przepustowość FullTraversalConnector:
| Ustawienie | Opis | Domyślny | Zmiana konfiguracji do wypróbowania |
|---|---|---|---|
traverse.partitionSize |
Liczba ApiOperation(), które mają być przetwarzane partiami przed pobraniem kolejnych APIOperation(). Zanim pobiera kolejne elementy, SDK czeka na przetworzenie bieżącego partycji. To ustawienie zależy od dostępnej ilości pamięci. Mniejsze partycje, np. 50 lub 100, wymagają mniej pamięci, ale powodują dłuższe oczekiwanie ze strony pakietu SDK. |
50 | Jeśli masz dużo dostępnej pamięci, spróbuj zwiększyć wartość parametru partitionSize do 1000 lub więcej. |
batch.batchSize |
Liczba żądań zebranych w jedną grupę. Po zakończeniu partycjonowania pakiet SDK czeka, aż wszystkie zbiorcze żądania zostaną przetworzone z partycji. W przypadku większych partii czas oczekiwania jest dłuższy. | 10 | Spróbuj zmniejszyć rozmiar partii. |
batch.maxActiveBatches |
Liczba dozwolonych równoczesnych partii. | 20 | Jeśli obniżysz wartość batchSize, musisz zwiększyć wartość maxActiveBatches zgodnie z tą formułą: maxActiveBatches = (partitionSize / batchSize) + 50. Jeśli np. partititionSize = 1000, a batchSize = 5, to maxActiveBatches = 250. Dodatkowe 50 to bufor dla próśb o ponowne próby. Dzięki temu zwiększeniu sprzęg może grupować wszystkie żądania bez blokowania. |
traverse.threadPoolSize |
Liczba wątków tworzonych przez konwerter, aby umożliwić przetwarzanie równoległe. Pojedynczy iterator pobiera operacje (zazwyczaj obiekty RepositoryDoc) w kolejności, ale wywołania interfejsu API są przetwarzane równolegle za pomocą określonej liczby wątków (threadPoolSize). Każdy wątek przetwarza po jednym elemencie naraz. Domyślna wartość 50 przetwarzałaby maksymalnie 50 elementów jednocześnie, a przetworzenie pojedynczego elementu (w tym żądanie indeksowania) zajmuje około 4 sekund. |
50 | Spróbuj zwiększyć threadPoolSize o wielokrotność 10. |
Na koniec zastanów się nad użyciem metody setRequestMode(), aby zmienić tryb żądania interfejsu API (ASYNCHRONOUS lub SYNCHRONOUS).
Więcej informacji o parametrach pliku konfiguracji znajdziesz w artykule Parametry konfiguracji dostarczane przez Google.
Przepustowość indeksowania jest niska w przypadku ListTraversalConnector
Domyślnie łącznik, który implementuje interfejs ListTraversalConnnector, używa pojedynczego przeszukiwacza do indeksowania elementów. Aby zwiększyć wydajność indeksowania, możesz utworzyć kilka przeszukiwarek z osobną konfiguracją, która będzie się koncentrować na określonych stanach elementów (NEW_ITEM, MODIFIED itp.). W tabeli poniżej znajdziesz ustawienia konfiguracji, które poprawiają przepustowość:
| Ustawienie | Opis | Domyślny | Zmiana konfiguracji do wypróbowania |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Tworzy co najmniej 1 pojedynczą funkcję przeszukiwania, gdzie t1, t2, t3, ... jest unikalną nazwą każdej z nich. Każdy nazwany obiekt Traversor ma własny zestaw ustawień, który jest identyfikowany za pomocą unikalnej nazwy obiektu Traversor, np. traversers.t1.hostload i traversers.t2.hostload. | Jeden przechodnik | Użycie tego ustawienia pozwala dodać dodatkowych wędrowców |
traversers.t1.hostload = n | Określa liczbę wątków (n), które mają być używane do jednoczesnego indeksowania elementów. | 5 | Eksperymentuj z dostosowaniem n na podstawie obciążenia, jakie chcesz przypisać do repozytorium. Zacznij od wartości 10 lub wyższej. |
schedule.pollQueueIntervalSecs = s | Określa liczbę sekund s, przez jaką usługa będzie czekać przed ponownym przeprowadzeniem ankiety . Połączenie treści będzie nadal przeprowadzać ankietę dotyczącą elementów, dopóki interfejs API będzie zwracać elementy w odpowiedzi na ankietę. Gdy odpowiedź na zapytanie jest pusta, konektor czeka s sekund, zanim spróbuje ponownie. To ustawienie jest używane tylko przez ListingConnector | 10 | Spróbuj zmniejszyć tę wartość do 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Określa stany status1, status2, … elementów do zindeksowania. Na przykład ustawienie wartości status1 na NEW_ITEM i status2 na MODIFIED powoduje, że przeszukiwarka t1 indeksuje tylko elementy o tych stanach. | Jeden przeszukiwacz sprawdza wszystkie stany | Eksperymentuj z użyciem różnych przechodnich w przypadku różnych stanów. |
Więcej informacji o parametrach pliku konfiguracji znajdziesz w artykule Parametry konfiguracji dostarczane przez Google.
Pakiet SDK się przerywa lub kończy podczas przesyłania dużych plików
Jeśli podczas przesyłania dużych plików wystąpi przekroczenie limitu czasu lub przerwanie działania pakietu SDK, określ dłuższy czas oczekiwania za pomocą parametru traverser.timeout=s (gdzie s = liczba sekund). Ta wartość określa, ile czasu wątki robocze mają na przetworzenie elementu. Domyślny limit czasu w pakiecie SDK to 60 sekund dla wątków przeszukiwania. Jeśli masz problemy z czasem oczekiwania na odpowiedź na poszczególne żądania interfejsu API, możesz zwiększyć czas oczekiwania na odpowiedź, wykonując te czynności:
| Parametr limitu czasu żądania | Opis | Domyślny |
|---|---|---|
indexingService.connectTimeoutSeconds |
Czas oczekiwania na połączenie w przypadku żądań indeksowania interfejsu API. | 120 sekund. |
indexingService.readTimeoutSeconds |
Przeczytaj informacje o czasie oczekiwania na żądania indeksowania interfejsu API. | 120 sekund. |