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

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 को निर्देश मिलता है कि वह सिर्फ़ इन स्टेटस वाले आइटम को इंडेक्स करे.	एक ट्रैवर्सर सभी स्टेटस की जांच करता है	अलग-अलग स्टेटस के लिए, अलग-अलग ट्रैवर्सर पोल की मदद से एक्सपेरिमेंट करें.

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

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

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

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