Google Cloud Search SDK berisi beberapa parameter konfigurasi yang disediakan Google yang digunakan oleh semua konektor. Mengetahui cara menyesuaikan pengaturan ini dapat menyederhanakan pengindeksan data secara signifikan. Panduan ini mencantumkan beberapa masalah yang dapat muncul selama pengindeksan dan setelan yang digunakan untuk menyelesaikannya.
Throughput pengindeksan rendah untuk FullTraversalConnector
Tabel berikut mencantumkan setelan konfigurasi guna meningkatkan throughput untuk FullTraversalConnector:
| Pembahasan | Deskripsi | Default | Perubahan konfigurasi untuk dicoba |
|---|---|---|---|
traverse.partitionSize |
Jumlah ApiOperation() yang akan diproses dalam beberapa batch sebelum mengambil APIOperation() tambahan. SDK menunggu partisi saat ini diproses sebelum mengambil item tambahan. Setelan ini bergantung pada jumlah memori yang tersedia. Ukuran partisi yang lebih kecil, seperti 50 atau 100, memerlukan lebih sedikit memori, tetapi lebih banyak menunggu untuk SDK. |
50 | Jika Anda memiliki banyak memori yang tersedia, coba tingkatkan partitionSize menjadi 1.000 atau lebih. |
batch.batchSize |
Jumlah permintaan yang dikelompokkan. Pada akhir partisi, SDK akan menunggu semua permintaan dalam batch diproses dari partisi. Batch yang lebih besar memerlukan waktu tunggu yang lebih lama. | 10 | Coba kurangi ukuran tumpukan. |
batch.maxActiveBatches |
Jumlah batch yang dapat dieksekusi secara serentak yang diizinkan. | 20 | Jika menurunkan batchSize, Anda akan menambahkan maxActiveBatches sesuai dengan formula ini: maxActiveBatches = (partitionSize / batchSize) + 50. Misalnya, jika partititionSize adalah 1000 dan batchSize adalah 5, maxActiveBatches harus 250. 50 ekstra tersebut adalah buffering untuk permintaan percobaan ulang. Peningkatan ini memungkinkan konektor mengelompokkan semua permintaan tanpa memblokir. |
traverse.threadPoolSize |
Jumlah thread yang dibuat konektor untuk memungkinkan pemrosesan paralel. Iterator tunggal mengambil operasi (biasanya objek RepositoryDoc) secara berurutan, tetapi API memanggil proses secara paralel menggunakan jumlah thread threadPoolSize. Setiap thread memproses item satu per satu. Nilai default 50 hanya akan memproses maksimal 50 item secara bersamaan dan perlu waktu sekitar 4 detik untuk memproses masing-masing item (termasuk permintaan pengindeksan). |
50 | Coba tingkatkan threadPoolSize dengan kelipatan 10. |
Terakhir, pertimbangkan untuk menggunakan metode setRequestMode() untuk mengubah mode permintaan API (ASYNCHRONOUS atau SYNCHRONOUS).
Untuk mengetahui informasi tambahan tentang parameter file konfigurasi, lihat parameter konfigurasi yang disediakan Google.
Throughput pengindeksan rendah untuk ListTraversalConnector
Secara default, konektor yang menerapkan ListTraversalConnnector menggunakan satu traverser untuk mengindeks item Anda. Untuk meningkatkan throughput pengindeksan, Anda dapat membuat beberapa traverser masing-masing dengan konfigurasinya sendiri yang berfokus pada status item tertentu (NEW_ITEM, MODIFIED, dan seterusnya). Tabel berikut mencantumkan setelan konfigurasi untuk meningkatkan throughput:
| Pembahasan | Deskripsi | Default | Perubahan konfigurasi untuk dicoba |
|---|---|---|---|
repository.traversers = t1, t2, t3, ... | Membuat satu atau beberapa traverser individual dengan t1, t2, t3, ... adalah nama unik masing-masing. Setiap traverser bernama memiliki kumpulan setelan sendiri yang diidentifikasi menggunakan nama unik traverser, seperti traversers.t1.hostload dan traversers.t2.hostload | Satu penjelajah | Gunakan setelan ini untuk menambahkan traverser tambahan |
traversers.t1.hostload = n | Mengidentifikasi jumlah thread, n, yang akan digunakan untuk mengindeks item secara bersamaan. | 5 | Lakukan eksperimen dengan menyesuaikan n berdasarkan seberapa banyak beban yang ingin Anda tempatkan di repositori. Mulai dengan nilai 10 atau lebih tinggi. |
schedule.pollQueueIntervalSecs = s | Mengidentifikasi jumlah detik, s, untuk menunggu sebelum polling ulang . Konektor konten terus melakukan polling item selama API menampilkan item dalam respons polling. Jika respons polling kosong, konektor akan menunggu selama s detik sebelum mencoba lagi. Setelan ini hanya digunakan oleh ListingConnector | 10 | Coba turunkan ke 1. |
traverser.t1.pollRequest.statuses = status1, status2, … | Menentukan status status1, status2, … item yang akan diindeks. Misalnya, menyetel status1 ke NEW_ITEM dan status2 ke MODIFIED akan menginstruksikan penjelajah t1 untuk hanya mengindeks item dengan status tersebut. | Satu pelintas memeriksa semua status | Lakukan eksperimen dengan melakukan polling penjelajah untuk berbagai status. |
Untuk mengetahui informasi tambahan tentang parameter file konfigurasi, lihat parameter konfigurasi yang disediakan Google.
Waktu tunggu SDK atau gangguan saat mengupload file besar
Jika Anda mengalami gangguan atau waktu tunggu SDK saat mengupload file besar,
tentukan waktu tunggu yang lebih besar menggunakan
traverser.timeout=s
(dengan s = jumlah detik). Nilai ini mengidentifikasi berapa lama thread pekerja
harus memproses item. Waktu tunggu default di SDK adalah 60 detik untuk thread traverser. Selain itu, jika Anda mengalami setiap permintaan API
waktu tunggu habis, gunakan metode berikut untuk meningkatkan nilai waktu tunggu permintaan:
| Parameter waktu tunggu permintaan | Deskripsi | Default |
|---|---|---|
indexingService.connectTimeoutSeconds |
Waktu tunggu koneksi untuk permintaan API pengindeksan. | 120 detik. |
indexingService.readTimeoutSeconds |
Waktu tunggu pembacaan untuk permintaan API pengindeksan. | 120 detik. |