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

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

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

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

खास जानकारी

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

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

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

मल्टीप्लेक्स वर्कर का फ़ायदा पाने के लिए, नियम की वर्कर प्रोसेस मल्टी-थ्रेड होनी चाहिए. प्रोटोबफ़, नियम सेट को एक ही अनुरोध को पार्स करने की अनुमति देता है, भले ही स्ट्रीम में कई अनुरोध इकट्ठा हो जाएं. जब भी वर्कर प्रोसेस, स्ट्रीम से किसी अनुरोध को पार्स करती है, तो उसे अनुरोध को नए थ्रेड में हैंडल करना चाहिए. क्योंकि अलग-अलग थ्रेड एक ही समय पर पूरा हो सकता है और स्ट्रीम में लिख सकता है, इसलिए वर्कर प्रोसेस को यह पक्का करने की ज़रूरत होती है कि रिस्पॉन्स एक-दूसरे के बिना लिखे गए हों (मैसेज ओवरलैप नहीं होते). जवाबों में उस अनुरोध का 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-multiplex-workers को supports-workers से ज़्यादा प्राथमिकता दी जाती है. --noworker_multiplex पास करके, मल्टीप्लेक्स वर्कर को दुनिया भर में बंद किया जा सकता है.

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

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

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

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

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

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