इस पेज पर मल्टीप्लेक्स वर्कर के बारे में जानकारी दी गई है. इसमें, मल्टीप्लेक्स के साथ काम करने वाले कोड लिखने का तरीका बताया गया है और समाधान शामिल कर सकते हैं.
मल्टीप्लेक्स वर्कर, बेज़ल को एक ही वर्कर के लिए किए गए कई अनुरोधों को मैनेज करने की अनुमति देते हैं प्रोसेस. बहु-थ्रेड वाले वर्कर के लिए, Baze कम संसाधन इस्तेमाल कर सकते हैं उसी या बेहतर प्रदर्शन को पूरा कर सकें. उदाहरण के लिए, हर कर्मचारी की तय की गई प्रक्रिया के आधार पर, बेज़ेल में एक से ज़्यादा चार लोग काम कर सकते हैं. वही वर्कर प्रोसेस, जो अनुरोधों को साथ-साथ हैंडल कर सकती है. Java और Scala जैसी भाषाओं के लिए, इससे JVM को गर्म होने में लगने वाला समय और JIT कंपाइलेशन में लगने वाला समय कम हो जाता है. आम तौर पर, इससे एक ही तरह के सभी वर्कर के बीच एक शेयर किए गए कैश मेमोरी का इस्तेमाल किया जा सकता है.
खास जानकारी
Bazel सर्वर और वर्कर्स प्रोसेस के बीच दो लेयर होती हैं. कुछ ऐसे mnemomics के लिए जो प्रोसेस को एक साथ चला सकते हैं, Bazel को वर्कर्स पूल से WorkerProxy मिलता है. WorkerProxy, वर्कर प्रोसेस पर अनुरोधों को फ़ॉरवर्ड करता है
request_id के साथ-साथ, कर्मचारी अनुरोध को प्रोसेस करता है
और WorkerMultiplexer को प्रतिक्रियाएं भेजता है. जब WorkerMultiplexer
एक जवाब मिलता है, तो यह request_id को पार्स करता है और फिर जवाबों को फ़ॉरवर्ड करता है
सही WorkerProxy पर वापस जाएं. नॉन-मल्टीप्लेक्स किए गए वर्कर्स की तरह ही, सभी कम्यूनिकेशन स्टैंडर्ड इन/आउट के ज़रिए किया जाता है. हालांकि, टूल सिर्फ़ उपयोगकर्ता को दिखने वाले आउटपुट के लिए stderr का इस्तेमाल नहीं कर सकता (नीचे देखें).
हर कर्मचारी के पास एक पासकोड होता है. Bazel, कुंजी के हैश कोड (पर्यावरण के वैरिएबल, रनटाइम रूट, और मेनिमोनिक से बना) का इस्तेमाल करके यह तय करता है कि किस WorkerMultiplexer का इस्तेमाल करना है. अगर WorkerProxy का हैश कोड एक जैसा है, तो वे एक ही WorkerMultiplexer के साथ कम्यूनिकेट करते हैं. इसलिए, यह मानकर
सिंगल बेज़ल में एनवायरमेंट वैरिएबल और एक्ज़ीक्यूशन रूट एक जैसे होते हैं
शुरू करना, हर याददाश्त में सिर्फ़ एक WorkerMultiplexer और एक हो सकता है
कर्मचारी की प्रोसेस. काम करने वाले लोगों की कुल संख्या. इनमें नियमित रूप से काम करने वाले लोग और
WorkerProxy, अब भी --worker_max_instances तक सीमित है.
मल्टीप्लेक्स के साथ काम करने वाले नियम लिखना
फ़ायदा पाने के लिए नियम की वर्कर प्रोसेस मल्टी-थ्रेड होनी चाहिए
मल्टीप्लेक्स वर्कर. Protobuf की मदद से, नियमों के सेट में किसी एक अनुरोध को पार्स किया जा सकता है. भले ही, स्ट्रीम में कई अनुरोध हो सकते हैं. जब भी
वर्कर प्रोसेस, स्ट्रीम से अनुरोध को पार्स करती है. इसे
नया थ्रेड. अलग-अलग थ्रेड एक ही समय पर पूरी हो सकती हैं और स्ट्रीम में लिखी जा सकती हैं. इसलिए, वर्क प्रोसेस को यह पक्का करना होगा कि जवाब एक-एक करके लिखे जाएं (मैसेज ओवरलैप न हों). जवाबों में, उस अनुरोध का request_id शामिल होना चाहिए जिसे प्रोसेस किया जा रहा है.
मल्टीप्लेक्स आउटपुट मैनेज करना
मल्टीप्लेक्स वर्कर को अपने आउटपुट को मैनेज करने में, सिंगलप्लेक्स वर्कर की तुलना में ज़्यादा सावधानी बरतनी पड़ती है. stderr पर भेजा गया कोई भी डेटा, एक ही तरह के सभी WorkerProxy के बीच शेयर की जाने वाली एक लॉग फ़ाइल में जाएगा. यह डेटा, एक साथ किए गए अनुरोधों के बीच, रैंडम तरीके से इंटरलीव किया जाएगा. stdout को रीडायरेक्ट करते समय
stderr में बदलना अच्छा आइडिया है, उस आउटपुट को output में इकट्ठा न करें
फ़ील्ड के तौर पर WorkResponse का एक फ़ील्ड भी शामिल करना होगा, क्योंकि यह उपयोगकर्ता को टूटी-फूटी आउटपुट सामग्री दिखा सकता है.
अगर आपका टूल सिर्फ़ 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 को पास करके, मल्टीप्लेक्स वर्कर्स को पूरी तरह से बंद किया जा सकता है.
हमारा सुझाव है कि अगर हो सके, तो मल्टीप्लेक्स वर्कर्स का इस्तेमाल करें. इससे मेमोरी पर दबाव कम होगा और परफ़ॉर्मेंस बेहतर होगी. हालांकि, मल्टीप्लेक्स वर्कर्स फ़िलहाल डाइनैमिक तरीके से लागू होने वाले टेंप्लेट के साथ काम नहीं करते. ऐसा तब तक होता है, जब तक वे मल्टीप्लेक्स सैंडबॉक्सिंग लागू नहीं कर देते. डाइनैमिक तरीके से लागू होने वाले टास्क के लिए, बिना सैंडबॉक्स वाले मल्टीप्लेक्स वर्कर्स को चलाने की कोशिश करने पर, सैंडबॉक्स वाले सिंगलप्लेक्स वर्कर्स का इस्तेमाल किया जाएगा.
मल्टीप्लेक्स सैंडबॉक्सिंग
मल्टीप्लेक्स वर्कर को कर्मचारी लागू करना. सिंगलप्लेक्स वर्कर सैंडबॉक्सिंग का काम अपने सैंडबॉक्स में हर वर्कर प्रोसेस को चला रहा है, तो मल्टीप्लेक्स वर्कर एकाधिक समानांतर अनुरोधों के बीच काम करने वाली डायरेक्ट्री को प्रोसेस करें. मल्टीप्लेक्स वर्कर्स को सैंडबॉक्स करने की अनुमति देने के लिए, वर्कर्स को सीधे अपनी वर्किंग डायरेक्ट्री के बजाय, हर अनुरोध में बताई गई सबडायरेक्ट्री से पढ़ने और उसमें लिखने की सुविधा होनी चाहिए.
मल्टीप्लेक्स सैंडबॉक्सिंग की सुविधा के लिए, वर्कर को sandbox_dir फ़ील्ड का इस्तेमाल करना होगा
WorkRequest से कॉपी करें और उसका इस्तेमाल सभी फ़ाइलों के पढ़ने और लिखने के लिए प्रीफ़िक्स के तौर पर करें.
सैंडबॉक्स से बाहर रखे गए अनुरोध की तुलना में, arguments और inputs फ़ील्ड में कोई बदलाव नहीं होता. हालांकि, असल इनपुट sandbox_dir से मिलते-जुलते होते हैं. बदले गए इस पाथ से पढ़ने के लिए, वर्कफ़्लो को arguments और inputs में मिले फ़ाइल पाथ का अनुवाद करना होगा. साथ ही, उसे sandbox_dir से जुड़े सभी आउटपुट भी लिखने होंगे.
इसमें '.' जैसे पाथ के साथ-साथ, आर्ग्युमेंट में बताई गई फ़ाइलों में मिले पाथ भी शामिल होते हैं. जैसे, "argfile" आर्ग्युमेंट.
जब कोई वर्कफ़्लो, मल्टीप्लेक्स सैंडबॉक्सिंग की सुविधा के साथ काम करता है, तब नियमों का सेट, किसी कार्रवाई के execution_requirements में supports-multiplex-sandboxing जोड़कर इस सुविधा के साथ काम करने की जानकारी दे सकता है. अगर --experimental_worker_multiplex_sandboxing फ़्लैग पास किया जाता है या वर्कर्स का इस्तेमाल डाइनैमिक तरीके से किया जाता है, तो Bazel मल्टीप्लेक्स सैंडबॉक्सिंग का इस्तेमाल करेगा.
किसी सैंडबॉक्स किए गए मल्टीप्लेक्स वर्कर की वर्कर फ़ाइलें अब भी
वर्कर प्रोसेस की वर्किंग डायरेक्ट्री. इस तरह, अगर कोई फ़ाइल
का उपयोग वर्कर को चलाने के लिए और इनपुट के रूप में दोनों पर किया जाता है, तो इसे दोनों
फ़्लैग फ़ाइल आर्ग्युमेंट के साथ-साथ tools, executable या
runfiles.