इस पेज का अनुवाद Cloud Translation API से किया गया है.

कनेक्टर की सेटिंग को ट्यून करें

Google Cloud Search SDK में, Google की ओर से दिए गए कई कॉन्फ़िगरेशन पैरामीटर होते हैं. इनका इस्तेमाल सभी कनेक्टर करते हैं. इन सेटिंग को ट्यून करने का तरीका जानने से, डेटा को इंडेक्स करने की प्रोसेस को काफ़ी हद तक आसान बनाया जा सकता है. इस गाइड में, इंडेक्सिंग के दौरान आने वाली कई समस्याओं के बारे में बताया गया है. साथ ही, उन्हें हल करने के लिए इस्तेमाल की जाने वाली सेटिंग के बारे में भी बताया गया है.

FullTraversalConnector के लिए इंडेक्सिंग थ्रूपुट कम है

नीचे दी गई टेबल में, FullTraversalConnector के थ्रूपुट को बेहतर बनाने के लिए कॉन्फ़िगरेशन सेटिंग दी गई हैं:

सेटिंग	ब्यौरा	डिफ़ॉल्ट	कॉन्फ़िगरेशन में बदलाव करने की कोशिश करें
`traverse.partitionSize`	यह बताता है कि अतिरिक्त `APIOperation()` फ़ेच करने से पहले, बैच में प्रोसेस किए जाने वाले `ApiOperation()` की संख्या कितनी है. एसडीके, मौजूदा पार्टीशन के प्रोसेस होने का इंतज़ार करता है. इसके बाद ही, वह अन्य आइटम फ़ेच करता है. यह सेटिंग, उपलब्ध मेमोरी पर निर्भर करती है. पार्टिशन का साइज़ छोटा होने पर, जैसे कि 50 या 100, कम मेमोरी की ज़रूरत होती है. हालांकि, एसडीके को ज़्यादा इंतज़ार करना पड़ता है.	50	अगर आपके पास काफ़ी मेमोरी उपलब्ध है, तो `partitionSize` को 1,000 या इससे ज़्यादा पर सेट करें.
`batch.batchSize`	एक साथ बैच किए गए अनुरोधों की संख्या. एसडीके, पार्टीशनिंग के आखिर में, बैच किए गए सभी अनुरोधों के प्रोसेस होने का इंतज़ार करता है. बड़े बैच को प्रोसेस होने में ज़्यादा समय लगता है.	10	बैच का साइज़ कम करके देखें.
`batch.maxActiveBatches`	एक साथ चलने वाले बैच की अनुमति वाली संख्या.	20	अगर आपने `batchSize` की वैल्यू कम की है, तो आपको `maxActiveBatches` की वैल्यू इस फ़ॉर्मूले के हिसाब से बढ़ानी चाहिए: `maxActiveBatches = (partitionSize / batchSize`) + 50. उदाहरण के लिए, अगर आपका `partititionSize` 1,000 है और आपका `batchSize` 5 है, तो आपका `maxActiveBatches` 250 होना चाहिए. 50 का बफ़र, फिर से कोशिश करने के अनुरोधों के लिए होता है. इस बढ़ोतरी से कनेक्टर, सभी अनुरोधों को बिना ब्लॉक किए बैच कर सकता है.
`traverse.threadPoolSize`	कनेक्टर, पैरलल प्रोसेसिंग के लिए कितनी थ्रेड बनाता है. एक ही इटरेटर, कार्रवाइयों (आम तौर पर `RepositoryDoc` ऑब्जेक्ट) को क्रम से फ़ेच करता है. हालांकि, एपीआई कॉल, `threadPoolSize` थ्रेड की संख्या का इस्तेमाल करके एक साथ प्रोसेस होते हैं. हर थ्रेड, एक बार में एक आइटम प्रोसेस करती है. डिफ़ॉल्ट रूप से 50 आइटम एक साथ प्रोसेस किए जाते हैं. साथ ही, किसी एक आइटम को प्रोसेस करने में करीब चार सेकंड लगते हैं. इसमें इंडेक्स करने का अनुरोध भी शामिल है.	50	`threadPoolSize` को 10 के गुणज से बढ़ाने की कोशिश करें.

आखिर में, एपीआई अनुरोध मोड (ASYNCHRONOUS या SYNCHRONOUS) बदलने के लिए, setRequestMode() तरीके का इस्तेमाल करें.

कॉन्फ़िगरेशन फ़ाइल के पैरामीटर के बारे में ज़्यादा जानकारी के लिए, Google की ओर से उपलब्ध कराए गए कॉन्फ़िगरेशन पैरामीटर लेख पढ़ें.

ListTraversalConnector के लिए इंडेक्सिंग थ्रूपुट कम है

डिफ़ॉल्ट रूप से, ListTraversalConnnector को लागू करने वाला कनेक्टर, आपके आइटम को इंडेक्स करने के लिए एक ट्रैवर्सर का इस्तेमाल करता है. इंडेक्सिंग थ्रूपुट बढ़ाने के लिए, एक से ज़्यादा ट्रैवर्सर बनाए जा सकते हैं. हर ट्रैवर्सर का अपना कॉन्फ़िगरेशन होता है, जो आइटम की खास स्थितियों (NEW_ITEM, MODIFIED वगैरह) पर फ़ोकस करता है. यहां दी गई टेबल में, थ्रूपुट को बेहतर बनाने के लिए कॉन्फ़िगरेशन सेटिंग दी गई हैं:

सेटिंग	ब्यौरा	डिफ़ॉल्ट	कॉन्फ़िगरेशन में बदलाव करने की कोशिश करें
`repository.traversers = t1, t2, t3, ...`	यह एक या इससे ज़्यादा ट्रैवर्सर बनाता है, जहां `t1, t2, t3, ...` हर ट्रैवर्सर का यूनीक नाम होता है. नाम वाले हर ट्रैवर्सर के लिए, सेटिंग का अपना सेट होता है. इनकी पहचान ट्रैवर्सर के यूनीक नाम से की जाती है. जैसे, `traversers.t1.hostload` और `traversers.t2.hostload`	एक ट्रैवर्सर	इस सेटिंग का इस्तेमाल करके, अतिरिक्त ट्रैवर्सर जोड़ना
`traversers.t1.hostload = n`	यह विकल्प, एक साथ कई आइटम को इंडेक्स करने के लिए इस्तेमाल किए जाने वाले थ्रेड की संख्या, `n` की पहचान करता है.	5	अपनी रिपॉज़िटरी पर कितना लोड डालना है, इसके आधार पर `n` को ट्यून करने का एक्सपेरिमेंट करें. वैल्यू 10 या उससे ज़्यादा से शुरू करें.
`schedule.pollQueueIntervalSecs = s`	यह कुकी, फिर से पोल करने से पहले इंतज़ार करने के लिए सेकंड की संख्या, `s` की पहचान करती है . जब तक एपीआई, पोल के जवाब में आइटम दिखाता है, तब तक कॉन्टेंट कनेक्टर आइटम को पोल करता रहता है. पोल के जवाब खाली होने पर, कनेक्टर `s` सेकंड तक इंतज़ार करता है. इसके बाद, वह फिर से कोशिश करता है. इस सेटिंग का इस्तेमाल सिर्फ़ ListingConnector करता है	10	इसे 1 पर सेट करके देखें.
`traverser.t1.pollRequest.statuses = status1, status2, …`	इससे इंडेक्स किए जाने वाले आइटम के स्टेटस, `status1`, `status2`, `…` के बारे में पता चलता है. उदाहरण के लिए, `status1` को `NEW_ITEM` और `status2` को `MODIFIED` पर सेट करने से, ट्रैवर्सर `t1` को सिर्फ़ उन आइटम को इंडेक्स करने का निर्देश मिलता है जिनके स्टेटस ये हैं.	एक ट्रैवर्सर, सभी स्टेटस की जांच करता है	अलग-अलग स्टेटस के लिए, अलग-अलग ट्रैवर्सर पोल करने की सुविधा आज़माएं.

बड़ी फ़ाइलें अपलोड करते समय एसडीके के टाइम आउट होने या रुकने की समस्या

अगर बड़ी फ़ाइलें अपलोड करते समय, आपको एसडीके के टाइम आउट होने या उसमें रुकावट आने की समस्या होती है, तो traverser.timeout=s का इस्तेमाल करके, टाइम आउट की अवधि बढ़ाएं. यहां s = सेकंड की संख्या है. इस वैल्यू से यह पता चलता है कि वर्कर थ्रेड को किसी आइटम को प्रोसेस करने में कितना समय लगता है. SDK टूल में, ट्रैवर्सर थ्रेड के लिए समय खत्म होने की डिफ़ॉल्ट अवधि 60 सेकंड होती है. इसके अलावा, अगर आपको एपीआई के किसी अनुरोध का समय खत्म होने की समस्या आ रही है, तो अनुरोध के समय खत्म होने की वैल्यू बढ़ाने के लिए, इन तरीकों का इस्तेमाल करें:

अनुरोध का समय खत्म होने का पैरामीटर	ब्यौरा	डिफ़ॉल्ट
`indexingService.connectTimeoutSeconds`	इंडेक्सिंग एपीआई के अनुरोधों के लिए कनेक्ट होने का समय खत्म हो गया.	120 सेकंड.
`indexingService.readTimeoutSeconds`	इंडेक्सिंग एपीआई के अनुरोधों के लिए रीड टाइमआउट.	120 सेकंड.