बिल्ड परफ़ॉर्मेंस का विश्लेषण

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

क्लीन बनाम इंक्रीमेंटल बिल्ड

क्लीन बिल्ड वह तरीका है जिसमें सब कुछ शुरुआत से बनाया जाता है. हालांकि, यह प्रोसेस थोड़ी इंक्रीमेंटल होती है बिल्ड पहले से पूरे हो चुके कुछ काम का दोबारा इस्तेमाल करता है.

हमारा सुझाव है कि आप साफ़ और इंक्रीमेंटल बिल्ड को अलग-अलग देखें. खास तौर पर तब, जब आपके पास ऐसी मेट्रिक इकट्ठा / एग्रीगेट करने की सुविधा है जो आपकी मौजूदा स्थिति पर निर्भर करती हैं बेज़ल की कैश मेमोरी (उदाहरण के लिए बिल्ड रिक्वेस्ट साइज़ मेट्रिक ). ये दो अलग-अलग उपयोगकर्ता अनुभव भी दिखाते हैं. शुरू होने की तुलना में शुरुआत से क्लीन बिल्ड (जिसे कोल्ड कैश मेमोरी की वजह से ज़्यादा समय लगता है), इंक्रीमेंटल बिल्ड बहुत बार होते हैं, क्योंकि डेवलपर कोड को बार-बार दोहराते हैं (आम तौर पर क्योंकि कैश आम तौर पर पहले से गर्म होता है).

बीईपी में CumulativeMetrics.num_analyses फ़ील्ड का इस्तेमाल करके, ये कैटगरी तय की जा सकती हैं बिल्ड. अगर num_analyses <= 1, तो यह एक क्लीन बिल्ड है; नहीं तो, हम बड़े पैमाने पर इसे एक इंक्रीमेंटल बिल्ड के तौर पर कैटगरी में बांट सकते हैं - अगर उपयोगकर्ता ने स्विच किया हो अलग-अलग झंडों या अलग-अलग टारगेट के लिए. कोई भी बढ़ोतरी की एक और सटीक परिभाषा इस्तेमाल करते हैं. उदाहरण के लिए, लोड किए गए पैकेज की संख्या को देखते हुए (PackageMetrics.packages_loaded).

बिल्ड परफ़ॉर्मेंस के लिए प्रॉक्सी के तौर पर, तय किए गए बिल्ड मेट्रिक

इन प्रॉडक्ट की परफ़ॉर्मेंस को मेज़र करना मुश्किल हो सकता है, क्योंकि ये सभी प्रॉडक्ट की परफ़ॉर्मेंस से जुड़ी जानकारी नहीं देते (उदाहरण के लिए, Basel का सीपीयू टाइम या रिमोट पर कतार में लगने वाला समय क्लस्टर). इसलिए, डिटरमिनिस्टिक मेट्रिक का इस्तेमाल प्रॉक्सी के रूप में Basel का काम है, जिससे कंपनी की परफ़ॉर्मेंस पर असर पड़ता है.

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

हम इस समस्या को बिल्ड के अलग-अलग चरणों में बांटकर, नीचे दिया गया तरीका इस्तेमाल कर सकते हैं हर चरण में पूरे किए जाने वाले काम के लिए प्रॉक्सी मेट्रिक के रूप में मेट्रिक:

1. PackageMetrics.packages_loaded: सफलतापूर्वक लोड हुए पैकेज की संख्या. यहां दिए गए रिग्रेशन से ऐसे ज़्यादा काम के बारे में पता चलता है जिन्हें पढ़ने और पार्स करने के लिए ज़्यादा काम करने की ज़रूरत होती है लोड होने के चरण में हर अतिरिक्त बिल्ड फ़ाइल.

   • ऐसा अक्सर डिपेंडेंसी की वजह से होता है. साथ ही, अस्थायी तौर पर बंद होने की जानकारी.
   • ढूंढने के लिए query / cquery का इस्तेमाल करें जहां नई डिपेंडेंसी जोड़ी गई होंगी.

2. TargetMetrics.targets_configured: टारगेट की संख्या और पहलुओं को बिल्ड में कॉन्फ़िगर किया गया है. रिग्रेशन के हिसाब से, कॉन्फ़िगर किए गए टारगेट ग्राफ़ को बनाना और उसे ट्रैक करना.

   • ऐसा अक्सर डिपेंडेंसी जोड़ने और कुछ कंस्ट्रक्शन की ज़रूरत होने की वजह से होता है समयसीमा खत्म होने का ग्राफ़ मिल सकता है.
   • cquery का इस्तेमाल करके जानें कि कहां नया डिपेंडेंसी जोड़ दी गई होंगी.

3. ActionSummary.actions_created: बिल्ड में बनाई गई कार्रवाइयों को दिखाता है. और रिग्रेशन से, ऐक्शन ग्राफ़ को बनाने में ज़्यादा काम का पता चलता है. नोट जोड़ें इनमें, इस्तेमाल न होने वाली वे कार्रवाइयां भी शामिल हैं जो शायद लागू नहीं की गई हैं.

   • रिग्रेशन को डीबग करने के लिए aquery का इस्तेमाल करें; हमारा सुझाव है कि आप --output=summary बेहतर ड्रिल-डाउन करने से पहले --skyframe_state.

4. ActionSummary.actions_executed: की गई कार्रवाइयों की संख्या रिग्रेशन सीधे तौर पर इन कार्रवाइयों को लागू करने के लिए ज़्यादा काम दिखाता है.

   • BEP कार्रवाई के आंकड़े लिखता है ActionData जो सबसे ज़्यादा की जाने वाली कार्रवाई के टाइप दिखाता है. डिफ़ॉल्ट रूप से, यह यह 20 तरह की टॉप ऐक्शन इकट्ठा करता है. हालांकि, आपके पास --experimental_record_metrics_for_all_mnemonics इस डेटा को सभी तरह की कार्रवाइयों के लिए इकट्ठा किया जा सकता है.
   • इससे आपको यह पता लगाने में मदद मिलेगी कि किस तरह की कार्रवाइयां की गई थीं (इसके अलावा).

5. BuildGraphSummary.outputArtifactCount: इतने आर्टफ़ैक्ट बनाए गए करने के लिए इस्तेमाल किया जा सकता है.

   • अगर लागू की जाने वाली कार्रवाइयों की संख्या नहीं बढ़ी है, तो नियम को लागू करने के तरीके को बदला गया.

ये सभी मेट्रिक, लोकल कैश मेमोरी की स्थिति से प्रभावित होती हैं. इसलिए, आपको आपको यह पक्का करना होगा कि जिन बिल्ड से ये मेट्रिक एक्सट्रैक्ट की जा रही हैं क्लीन बिल्ड.

हमने पाया है कि इनमें से किसी भी मेट्रिक में रिग्रेशन के साथ-साथ, वॉल टाइम, सीपीयू टाइम, और मेमोरी के इस्तेमाल में रिग्रेशन.

स्थानीय संसाधनों का उपयोग

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

बिताया गया समय

इन मेट्रिक में गड़बड़ियों की ज़्यादा संभावना होती है (और ये बिल्ड के डेटा से काफ़ी अलग हो सकते हैं) बनाने में समय लगेगा; खास तौर पर - वॉल टाइम, सीपीयू टाइम, और सिस्टम टाइम. आप baZ-bench का इस्तेमाल करके इन मेट्रिक के लिए एक बेंचमार्क होता है और पर्याप्त संख्या में --runs होने पर, आपके पास अपने आकलन की सांख्यिकीय महत्व को बढ़ाएं.

• वॉल टाइम, असल दुनिया में बीता समय है.

  • अगर सिर्फ़ वॉल टाइम रिग्रेशन है, तो हमारा सुझाव है कि JSON ट्रेस प्रोफ़ाइल और ढूंढी जा रही है इस्तेमाल किया जा सकता है. अगर ऐसा नहीं किया जाता है, तो वापस आने वाली मेट्रिक की जांच करें, क्योंकि इससे वॉल पर असर पड़ सकता था समय.

• सीपीयू टाइम, वह समय है जो उपयोगकर्ता कोड को लागू करने वाले सीपीयू की ओर से खर्च किया जाता है.

  • अगर दो प्रोजेक्ट में सीपीयू का टाइम रिग्रेशन होता है, तो हमारा सुझाव है कि आप ये समय इकट्ठा करें Starlark सीपीयू प्रोफ़ाइल. आपको --nobuild का इस्तेमाल इन कामों के लिए भी करना चाहिए बिल्ड को विश्लेषण वाले चरण तक सीमित कर सकते हैं, क्योंकि इसमें सबसे ज़्यादा सीपीयू से जुड़ा भारी काम हो गया है.

• सिस्टम का समय, कर्नेल में सीपीयू के ज़रिए बिताया गया समय होता है.

  • अगर सिस्टम का समय, रिग्रेशन में बदलता है, तो इसका मतलब ज़्यादातर I/O से है. ऐसा तब होता है, जब Baze ने इसकी जानकारी पढ़ ली हो फ़ाइलें शामिल की जा सकती हैं.

पूरे सिस्टम के हिसाब से लोड प्रोफ़ाइल बनाना

इसका उपयोग करके --experimental_collect_load_average_in_profiler बेज़ल 6.0 में पेश किया गया फ़्लैग, JSON ट्रेस प्रोफ़ाइलर यह जानकारी इकट्ठा करता है लागू होने के दौरान सिस्टम लोड की औसत वैल्यू.

पहला डायग्राम. ऐसी प्रोफ़ाइल जिसमें सिस्टम लोड का औसत शामिल है.

Basel के शुरू करने के दौरान ज़्यादा लोड इस बात का संकेत हो सकता है कि Baze चैनल के लिए शेड्यूल होता है आपकी मशीन के साथ-साथ बहुत ज़्यादा स्थानीय कार्रवाइयां. आपको यह जानना चाहिए कि अडजस्ट कर रही हूँ --local_cpu_resources और --local_ram_resources, खास तौर पर कंटेनर एनवायरमेंट में (कम से कम #16512 को मर्ज किया गया).

बेज़ल मेमोरी के इस्तेमाल की निगरानी करना

Basel की मेमोरी के इस्तेमाल की जानकारी पाने के दो मुख्य सोर्स हैं: Basel info और बीईपी.

• bazel info used-heap-size-after-gc: इसके बाद, बाइट में इस्तेमाल की गई मेमोरी की संख्या System.gc() को कॉल किया जा रहा है.

  • बेज़ल बेंच इस मेट्रिक के लिए मानदंड भी उपलब्ध कराता है.
  • इसके अलावा, peak-heap-size, max-heap-size, used-heap-size हैं और committed-heap-size (देखें दस्तावेज़), लेकिन कम प्रासंगिक होते हैं.

• BEP का MemoryMetrics.peak_post_gc_heap_size: इसमें सबसे ऊंचे JVM हीप साइज़ का साइज़ बाइट पोस्ट GC के बाद (सेटिंग आवश्यक है --memory_profile जो पूरी तरह से जीसी (जीसी) लागू करने की कोशिश करता है).

मेमोरी के इस्तेमाल में होने वाला रिग्रेशन, आम तौर पर बिल्ड रिक्वेस्ट साइज़ मेट्रिक्स, ऐसा अक्सर किसी नियम की डिपेंडेंसी या नियम में बदलाव की वजह से होता है लागू करना.

अगर आपको अपनी बैज की मेमोरी फ़ुटप्रिंट की ज़्यादा जानकारी चाहिए, तो हमारा सुझाव है कि आप पहले से मौजूद मेमोरी प्रोफ़ाइलर पढ़ें.

लगातार काम करने वाले कर्मचारियों की मेमोरी प्रोफ़ाइलिंग

वहीं, लगातार काम करने वाले लोगों की मदद से, बिल्ड को तेज़ी से पूरा करने में मदद मिल सकती है (खास तौर पर, अनुवाद की गई भाषाओं के मामले में) उनकी मेमोरी फ़ुटप्रिंट का इस्तेमाल करने से समस्या हो सकती है. Basel ने अपने कर्मचारियों, खास तौर पर, WorkerMetrics.WorkerStats.worker_memory_in_kb फ़ील्ड से पता चलता है कि कितनी मेमोरी है कर्मचारी इस्तेमाल करते हैं (स्मरणिक तरीकों से).

JSON ट्रेस प्रोफ़ाइलर भी कॉल शुरू करने के दौरान, कर्मचारियों की मेमोरी के इस्तेमाल को कलेक्ट करता है. --experimental_collect_system_network_usage फ़्लैग (Bazu 6.0 में नया) शामिल कर सकते हैं.

दूसरा डायग्राम. ऐसी प्रोफ़ाइल जिसमें कर्मचारियों की मेमोरी के इस्तेमाल की जानकारी शामिल हो.

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

रिमोट बिल्ड के लिए नेटवर्क ट्रैफ़िक की निगरानी करना

रिमोट एक्ज़ीक्यूशन में, Baze ऐसे आर्टफ़ैक्ट डाउनलोड करता है जिन्हें कार्रवाइयां की जा रही हैं. इसलिए, आपकी नेटवर्क बैंडविथ, परफ़ॉर्मेंस पर असर डाल सकती है को भी बनाए रखता है.

अगर बिल्ड के लिए रिमोट तौर पर एक्ज़ीक्यूशन का इस्तेमाल किया जा रहा है, तो शुरू करने के दौरान, नेटवर्क ट्रैफ़िक की निगरानी करने के लिए BEP से NetworkMetrics.SystemNetworkStats प्रोटो (--experimental_collect_system_network_usage पास करना ज़रूरी है).

इसके अलावा, JSON ट्रेस प्रोफ़ाइल आपको बिल्ड के दौरान पूरे सिस्टम के नेटवर्क के इस्तेमाल को देखने की सुविधा देता है --experimental_collect_system_network_usage फ़्लैग को पास करके (बेज़ल में नया 6.0) है.

तीसरी इमेज. ऐसी प्रोफ़ाइल जिसमें पूरे सिस्टम के नेटवर्क के इस्तेमाल की जानकारी शामिल है.

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

दूसरा विकल्प यह है कि सेव करने के लिए डिस्क की कैश मेमोरी डाउनलोड बैंडविथ.