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

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

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

FulltraversalConnector के लिए, इंडेक्स करने की प्रोसेस कम है

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

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

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

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

ListTraversalConnector के लिए, इंडेक्स करने की प्रोसेस कम है

ListTraversalConnector को लागू करने वाला कनेक्टर डिफ़ॉल्ट रूप से, सिंगल ट्रेवर्सर का इस्तेमाल करें. इंडेक्स करने की प्रोसेस बढ़ाने के लिए, कई ट्रैवर्सर बनाते हैं, जिनमें से हर एक का कॉन्फ़िगरेशन अपनी ज़रूरत के हिसाब से होता है आइटम की स्थितियां (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` सेकंड तक इंतज़ार करता है. इसके बाद, फिर से कोशिश करें. इस सेटिंग का इस्तेमाल सिर्फ़ ListingsConnector करता है	10	इसे घटाकर 1 करने की कोशिश करें.
`traverser.t1.pollRequest.statuses = status1, status2, …`	इंडेक्स किए जाने वाले आइटम की स्थितियों (`status1`, `status2`, `…`) के बारे में बताता है. उदाहरण के लिए, `status1` को `NEW_ITEM` और `status2` को `MODIFIED` पर सेट करने से, ट्रेवरर `t1` को निर्देश मिलता है कि वह सिर्फ़ इन स्टेटस वाले आइटम को इंडेक्स करे.	एक ट्रैवर्सर सभी स्टेटस की जांच करता है	अलग-अलग स्टेटस के लिए, अलग-अलग ट्रैवर्सर पोल की मदद से एक्सपेरिमेंट करें.

बड़ी फ़ाइलें अपलोड करते समय, SDK टूल की टाइम आउट या रुक जाना

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

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