मल्टीप्लेक्स वर्कर (एक्सपेरिमेंटल फ़ीचर)

समस्या की शिकायत करें सोर्स देखें ठीक

इस पेज पर मल्टीप्लेक्स वर्कर, मल्टीप्लेक्स के साथ काम करने वाले नियम लिखने, और इससे जुड़ी कुछ सीमाओं के समाधान के बारे में जानकारी दी गई है.

चेतावनी: एक्सपेरिमेंट के तौर पर शुरू की गई सुविधाओं को किसी भी समय बदला जा सकता है.

मल्टीप्लेक्स वर्कर की मदद से, बेज़ल एक ही वर्कर प्रोसेस से कई अनुरोधों को मैनेज कर सकते हैं. एक से ज़्यादा थ्रेड वाले वर्कर के लिए, Baze उसी तरह के या बेहतर परफ़ॉर्मेंस पाने के लिए कम संसाधनों का इस्तेमाल कर सकता है. उदाहरण के लिए, हर कर्मचारी के लिए एक वर्कर प्रोसेस होने के बजाय, बेज़ल के पास एक ही वर्कर प्रोसेस से बात करने वाले चार मल्टीप्लेक्स वर्कर हो सकते हैं जो अनुरोधों को साथ-साथ हैंडल कर सकते हैं. Java और स्काला जैसी भाषाओं के लिए, इससे JVM वॉर्म-अप समय और JIT को कंपाइल करने में लगने वाला समय बचता है. सामान्य तौर पर, इससे एक ही तरह के सभी वर्कर के बीच, शेयर की गई एक कैश मेमोरी का इस्तेमाल किया जा सकता है.

खास जानकारी

बेज़ेल सर्वर और वर्कर प्रोसेस के बीच दो लेयर होती हैं. कुछ याद रखने की चीज़ों के लिए, बेज़ल को वर्कर पूल से WorkerProxy मिलता है. ऐसा उन चीज़ों के लिए होता है जो साथ-साथ प्रोसेस भी कर सकते हैं. WorkerProxy, वर्कर प्रोसेस पर request_id के साथ एक क्रम में अनुरोधों को फ़ॉरवर्ड करता है. वर्कर प्रोसेस, अनुरोध को प्रोसेस करती है और WorkerMultiplexer को जवाब भेजती है. जब WorkerMultiplexer को कोई जवाब मिलता है, तो यह request_id को पार्स करता है. इसके बाद, जवाबों को सही WorkerProxy पर फ़ॉरवर्ड करता है. नॉन-मल्टीप्लेक्स किए गए वर्कर की तरह ही, सभी कम्यूनिकेशन स्टैंडर्ड इन/आउट पर किए जाते हैं. हालांकि, यह टूल उपयोगकर्ता को दिखने वाले आउटपुट के लिए, सिर्फ़ stderr का इस्तेमाल नहीं कर सकता (नीचे देखें).

हर कर्मचारी के पास एक कुंजी होती है. Baज़ल, कुंजी का हैश कोड इस्तेमाल करता है. इसमें एनवायरमेंट वैरिएबल, एक्ज़ीक्यूशन रूट, और मेनेमोनिक शामिल होते हैं. इससे यह तय किया जाता है कि किस WorkerMultiplexer का इस्तेमाल करना है. अगर WorkerProxy का हैश कोड एक ही है, तो वे उसी WorkerMultiplexer से संपर्क करते हैं. इसलिए, यह मानते हुए कि एक बेज़ल इन्वेशन में एनवायरमेंट वैरिएबल और एक्ज़ीक्यूशन रूट एक जैसे हैं, हर यूनीक मेनेमोनिक में सिर्फ़ एक WorkerMultiplexer और एक वर्कर प्रोसेस हो सकती है. कर्मचारियों की कुल संख्या अब भी --worker_max_instances से सीमित है. इसमें नियमित रूप से काम करने वाले लोग और WorkerProxy लोग भी शामिल हैं.

मल्टीप्लेक्स के साथ काम करने वाले नियम लिखना

मल्टीप्लेक्स वर्कर का फ़ायदा पाने के लिए, नियम की वर्कर प्रोसेस मल्टी-थ्रेड होनी चाहिए. Protobuf, नियमसेट को एक अनुरोध को पार्स करने की अनुमति देता है. भले ही, स्ट्रीम में कई अनुरोध इकट्ठा हों. जब भी वर्कर प्रोसेस, स्ट्रीम से अनुरोध को पार्स करती है, तो इसे नए थ्रेड में अनुरोध को हैंडल करना चाहिए. अलग-अलग थ्रेड एक ही समय में स्ट्रीम को पूरा करके उसमें लिख सकती हैं. इसलिए, वर्कर प्रोसेस को यह पक्का करने की ज़रूरत होती है कि जवाब एक ही तरीके से लिखे गए हों (मैसेज ओवरलैप न हों). जवाबों में उस अनुरोध का request_id शामिल होना चाहिए जिसे वे हैंडल कर रहे हैं.

मल्टीप्लेक्स आउटपुट मैनेज करना

मल्टीप्लेक्स वर्कर को सिंगलप्लेक्स वर्कर के मुकाबले, अपने आउटपुट को हैंडल करने के बारे में ज़्यादा सावधानी बरतनी चाहिए. stderr को भेजी गई सभी फ़ाइलें, एक ही तरह की सभी WorkerProxy के साथ शेयर की जाने वाली सिंगल लॉग फ़ाइल में चली जाएंगी. इन्हें एक साथ किए जाने वाले अनुरोधों के बीच किसी भी क्रम में शामिल किया जाएगा. हालांकि, stdout को stderr पर रीडायरेक्ट करना एक अच्छा तरीका है, लेकिन उस आउटपुट को WorkResponse के output फ़ील्ड में इकट्ठा न करें. ऐसा करने से, उपयोगकर्ता को आउटपुट के गलत हिस्से दिख सकते हैं. अगर आपका टूल सिर्फ़ stdout या stderr को उपयोगकर्ता के लिए बनाए गए आउटपुट को भेजता है, तो आपको मल्टीप्लेक्स वर्कर चालू करने से पहले उस तरीके को बदलना होगा.

मल्टीप्लेक्स वर्कर चालू किया जा रहा है

मल्टीप्लेक्स वर्कर, डिफ़ॉल्ट रूप से चालू नहीं होते हैं. नियमसेट किसी कार्रवाई के execution_requirements में supports-multiplex-workers टैग का इस्तेमाल करके, मल्टीप्लेक्स वर्कर को चालू कर सकता है (ठीक उसी तरह जैसे supports-workers टैग से सामान्य वर्कर चालू होते हैं). सामान्य कर्मचारियों का इस्तेमाल करते समय भी, कर्मचारियों की रणनीति को नियमों के स्तर पर (उदाहरण के लिए, --strategy=[some_mnemonic]=worker) या आम तौर पर रणनीति के स्तर पर (उदाहरण के लिए, --dynamic_local_strategy=worker,standalone.) तय करने की ज़रूरत होती है. किसी दूसरे फ़्लैग की ज़रूरत नहीं होती. अगर दोनों को सेट किया गया है, तो supports-workers के बजाय supports-multiplex-workers को प्राथमिकता दी जाती है. --noworker_multiplex को पास करके, मल्टीप्लेक्स वर्कर को दुनिया भर में बंद किया जा सकता है.

अगर संभव हो, तो नियमसेट को मल्टीप्लेक्स वर्कर का इस्तेमाल करने की सलाह दी जाती है. इससे मेमोरी का दबाव कम होता है और परफ़ॉर्मेंस बेहतर होती है. हालांकि, फ़िलहाल मल्टीप्लेक्स वर्कर डाइनैमिक एक्ज़ीक्यूशन के साथ तब तक काम नहीं करते, जब तक वे मल्टीप्लेक्स सैंडबॉक्सिंग की सुविधा चालू नहीं करते. डाइनैमिक एक्ज़ीक्यूशन के साथ, सैंडबॉक्स न किए गए मल्टीप्लेक्स वर्कर चलाने की कोशिश करने पर, इसके बजाय सैंडबॉक्स वाले सिंगलप्लेक्स वर्कर का इस्तेमाल बिना किसी रुकावट के होगा.

मल्टीप्लेक्स सैंडबॉक्सिंग

वर्कर को लागू करने के दौरान, मल्टीप्लेक्स वर्कर को साफ़ तौर पर सपोर्ट करके सैंडबॉक्स किया जा सकता है. सिंगलप्लेक्स वर्कर सैंडबॉक्सिंग, हर वर्कर प्रोसेस को उसके सैंडबॉक्स में चलाकर की जा सकती है. वहीं, मल्टीप्लेक्स वर्क, एक साथ कई काम करने वाले अनुरोधों के बीच प्रोसेस काम करने वाली डायरेक्ट्री को शेयर करते हैं. मल्टीप्लेक्स वर्कर की सैंडबॉक्सिंग की अनुमति देने के लिए, वर्कर को हर अनुरोध में तय की गई सबडायरेक्ट्री को पढ़ने और लिखने के लिए सहायता देनी चाहिए, न कि सीधे इसकी ऐक्टिव डायरेक्ट्री में.

मल्टीप्लेक्स सैंडबॉक्सिंग की सुविधा के लिए, वर्कर को WorkRequest से sandbox_dir फ़ील्ड का इस्तेमाल करना होगा. साथ ही, इसे सभी फ़ाइलों के पढ़ने और लिखने के प्रीफ़िक्स के तौर पर इस्तेमाल करना होगा. हालांकि, सैंडबॉक्स न किए गए अनुरोध से arguments और inputs फ़ील्ड में कोई बदलाव नहीं होता है. हालांकि, असल इनपुट sandbox_dir के आधार पर होते हैं. वर्कर को arguments और inputs में मिले फ़ाइल पाथ का अनुवाद करना होगा, ताकि वह इस बदले गए पाथ को पढ़ सके. साथ ही, sandbox_dir से जुड़े सभी आउटपुट भी लिखना ज़रूरी है. इसमें '.' जैसे पाथ शामिल हैं. साथ ही, आर्ग्युमेंट (जैसे, "orgfile" आर्ग्युमेंट) में बताई गई फ़ाइलों में मिलने वाले पाथ शामिल हैं.

जब कोई वर्कर मल्टीप्लेक्स सैंडबॉक्सिंग की सुविधा के साथ काम करता है, तो रूलसेट किसी कार्रवाई के execution_requirements में supports-multiplex-sandboxing को जोड़कर, इस सहायता का एलान कर सकता है. इसके बाद, अगर --experimental_worker_multiplex_sandboxing फ़्लैग पास हो जाता है या वर्कर का इस्तेमाल डाइनैमिक एक्ज़ीक्यूशन के साथ किया जाता है, तो Baze, मल्टीप्लेक्स सैंडबॉक्स का इस्तेमाल करेगा.

किसी सैंडबॉक्स किए गए मल्टीप्लेक्स वर्कर की वर्कर फ़ाइलें अब भी वर्कर प्रोसेस की वर्किंग डायरेक्ट्री से मिलती-जुलती हैं. इसलिए, अगर किसी फ़ाइल का इस्तेमाल वर्कर को चलाने के लिए और इनपुट के तौर पर किया गया है, तो इसे फ़्लैग फ़ाइल आर्ग्युमेंट के साथ-साथ tools, executable या runfiles, दोनों में इनपुट के तौर पर बताया जाना चाहिए.