नमस्कार, हेब्र!

मुझे लगता है कि लगभग हर कार्यक्रम में प्रवेश होता है। इसके अलावा, पहले से ही नए अनुप्रयोगों की संख्या में (जिसका अर्थ है समुद्री परिस्थितियों के साथ), लॉग अक्सर एक मुकाबला सर्वर पर महत्वपूर्ण हो जाते हैं।

हालांकि, इस तरह की तकनीक के महत्व और व्यापकता के बावजूद, मैंने देखा कि लोग अक्सर उनके साथ काम करते समय मानक गलतियां करते हैं। यह आलेख कई मामलों में .Net के व्यवहार का वर्णन करता है, हालांकि, मैंने जावा दुनिया से छोटे आवेषण किए, बस एक तुलना करने के लिए।

आवंटन (स्मृति आवंटन)

सबसे आम गलती (मेरी टिप्पणियों के अनुसार) कॉल के स्थान के पास log.Debug(...) फ़ंक्शन के पास छोटी मेमोरी आवंटन के संबंध में एक लापरवाही है।

तो, हमारे .Net में मानक कोड:

 private static readonly ILog Log4NetLog = LogManager.GetLogger(typeof(Program)); private static readonly Logger NLogLog = NLog.LogManager.GetCurrentClassLogger(); private static void PublishData(int id, string name, EMail email, decimal amount) { Log4NetLog.Debug($"Id={id}"); // 1 Log4NetLog.DebugFormat("Id={0}", id); // 2 Log4NetLog.Debug($"Id={id}; name={name}; email={email.Normalize()}; amount={amount}"); // 3 Log4NetLog.DebugFormat("Id={0}; name={1}; email={2}; amount={3}", id, name, email.Normalize(), amount); // 4 NLogLog.Debug($"Id={id}"); // 5 NLogLog.Debug("Id={0}", id); // 6 NLogLog.Debug($"Id={id}; name={name}; email={email.Normalize()}; amount={amount}"); // 7 NLogLog.Debug("Id={0}; name={1}; email={2}; amount={3}", id, name, email.Normalize(), amount); // 8 } 

कई मायनों में, मैंने केवल log4net और NLog पुस्तकालयों को देखा, और इसलिए मैं उन्हें उदाहरणों में उपयोग करूंगा।

तो सवाल ये हैं:

• यदि डिबग को बंद कर दिया जाता है, तो भी किन लाइनों को आवंटित किया जाएगा?
• यदि मेमोरी आवंटित की जाती है, तो एक ही डॉटट्रेस में यह पता लगाना कितना आसान है कि विशेष रूप से लॉगर को इस बहुत मेमोरी आवंटन के लिए दोषी ठहराया जाता है?

पहले प्रश्न का सही उत्तर: मेमोरी केवल "6" पैराग्राफ में आवंटित नहीं की गई है। और दूसरे प्रश्न का उत्तर: इसे पकड़ना अविश्वसनीय रूप से कठिन है, क्योंकि इस तरह के कोड अक्सर परियोजना पर फैले होते हैं। आप किसी विशिष्ट .Net अनुप्रयोग को याद कर सकते हैं। इसमें अक्सर समान कोड होता है जो GC काम करता है।

हालाँकि, तकनीकी विवरणों के माध्यम से समझते हैं कि प्रदर्शन पर क्या प्रभाव पड़ेगा।

तो पहला बिंदु:

 Log4NetLog.Debug($"Id={id}"); // 1 

वास्तव में, संकलक इसे रूपांतरित करेगा:

 var temp = string.Format("Id={0}", id); // <--       Log4NetLog.Debug(temp); 

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

दूसरा उदाहरण थोड़ा अधिक कुशल है, क्योंकि इसमें एक लाइन नहीं बनाई गई है:

 Log4NetLog.DebugFormat("Id={0}", id); 

हालाँकि, अभी भी यहां मेमोरी आवंटित की गई है, क्योंकि बॉक्सिंग होगी। मैं आपको डिबगफॉर्म विधि के हस्ताक्षर याद दिलाता हूं:

 void DebugFormat(string format, object arg0) 

जैसा कि आप देख सकते हैं, इनपुट के लिए एक संदर्भ प्रकार की आवश्यकता होती है। हालांकि, हम एक सार्थक int प्रकार को पारित करने की कोशिश कर रहे हैं। नतीजतन, प्रत्येक कॉल के परिणामस्वरूप विधि को पास करने के लिए हीप पैरामीटर id दिया जाएगा। और मैं आपको याद दिला दूं कि पैरामीटर को स्वयं विधि की आवश्यकता नहीं है, क्योंकि Debug कार्य की स्थिति से बंद है।

निम्न उदाहरण लोड और सरल है:

 Log4NetLog.Debug($"Id={id}; name={name}; email={email.Normalize()}; amount={amount}"); // 3 

मुझे यकीन है कि आप पहले से ही समझ गए थे कि फिर से लाइन ढेर पर खड़ी होगी और इसी तरह। इसलिए, तुरंत इस उदाहरण को छोड़ दें। निम्नलिखित कॉल विधि अधिक कुशल लगती है:

 Log4NetLog.DebugFormat("Id={0}; name={1}; email={2}; amount={3}", id, name, email.Normalize(), amount); // 4 

और ऐसा है, तथापि, आइए गणना करें कि स्मृति का एक टुकड़ा आवंटित करने के लिए कितनी बार आवश्यक है:

• email.Normalize() किसी प्रकार की वस्तु के निर्माण की ओर ले जाता है। इसलिए, यह ऑब्जेक्ट हीप (या स्टैक पर -) में आबंटित होगा, क्योंकि बॉक्सिंग से ढेर पर सब कुछ का चयन करना आवश्यक हो जाएगा)
• id एक ढेर में जाएगी, जैसा कि हमने पहले ही माना था।
• Log4net में इस तरह के लंबे स्वरूपित कॉल के लिए निम्नलिखित इंटरफ़ेस है: void DebugFormat(string format, params object[] args) । जैसा कि आप देख सकते हैं, .Net इसे DebugFormat विधि से पारित करने के लिए ढेर पर एक सरणी बनाएगा।

नतीजतन, लॉगिंग ऑपरेशन के लिए एक काफी विशिष्ट कॉल मेमोरी में वस्तुओं के ढेर के परिणामस्वरूप होगा। जो कि निराशाजनक है, क्योंकि लॉगिंग स्वयं अक्सर बंद हो जाती है। हालांकि, चलो NLog पर चलते हैं।

यह रेखा ढेर पर वस्तु के आवंटन को उकसाएगी:

 NLogLog.Debug($"Id={id}"); 

यहां सब कुछ स्पष्ट है, लेकिन अब नीचे की रेखा में ऐसी कोई कमी नहीं है:

 NLogLog.Debug("Id={0}", id); 

और इसका कारण यह है कि एनएलओजी के पास इनट्स के लिए एक विशेष हस्ताक्षर हैं: void Debug(string message, int argument) । इसके अलावा, यहां तक ​​कि अगर आप एक अलग संरचना को स्थानांतरित करते हैं, तो void Debug<TArgument>([Localizable(false)] string message, TArgument argument) । और इस पद्धति में मुक्केबाजी की आवश्यकता नहीं है, क्योंकि JIT के बाद प्रत्येक प्रकार के लिए एक अलग फ़ंक्शन बनाया जाएगा (बेशक, यह पूरी तरह से सच नहीं है, लेकिन महत्वपूर्ण बिंदु यह है: कोई मुक्केबाजी नहीं होगी)।

मैं बड़ी इनपुट लाइन के साथ आसानी से समझने वाली स्क्रिप्ट को छोड़ दूंगा और सीधे जाऊंगा:

 NLogLog.Debug("Id={0}; name={1}; email={2}; amount={3}", id, name, email.Normalize(), amount); 

ताज्जुब की बात है, NLog ने तरीकों के लिए जेनेरिक मापदंडों की संख्या में वृद्धि नहीं की, और इसलिए हस्ताक्षर का उपयोग किया जाएगा: void Debug([Localizable(false)] string message, params object[] args) । और यह फिर से और इतने पर वस्तुओं के निर्माण का नेतृत्व करेगा।

निष्कर्ष और सुधार

मुख्य निष्कर्ष: यदि आपके पास प्रोग्राम में लॉगिंग विधियों के लिए बहुत सारे कॉल हैं जो फ़ाइल को भौतिक लेखन की ओर नहीं ले जाते हैं, तो आप ढेर पर अनावश्यक वस्तुओं को आवंटित करने के लिए नीले रंग की शुरुआत से बाहर हो सकते हैं। और इस तरह कार्यक्रम का काम बाधित हो रहा है।

निष्कर्ष 2: यदि आप एक विधि में कई ऑब्जेक्ट नहीं पास करते हैं, तो NLog का उपयोग करें। इस तथ्य के कारण कि यह जेनेरिक मापदंडों का ध्यान रखता है, आप प्रदर्शन के बारे में अधिक आराम कर सकते हैं।

हालाँकि, पूरी तरह से सुरक्षित होने के लिए, ऐसा करना अधिक तर्कसंगत है:

 if (NLogLog.IsDebugEnabled) { NLogLog.Debug($"Id={id}; name={name}; email={email.Normalize()}; amount={amount}"); } 

यदि आवश्यक नहीं है तो यहां लॉगिंग विधि को नहीं बुलाया जाएगा। हालांकि, यदि आपको अभी भी लॉग में डेटा डंप करना है, तो सुविधाजनक स्ट्रिंग इंटरपोलेशन का उपयोग किया जाएगा। अंदर, लकड़हारे (कम से कम एक ही NLog) के पास सीधे लॉग में एक लाइन लिखने के लिए अनुकूलन है (यानी स्वरूपण तुरंत मेमोरी में एक लाइन बनाने के बजाय Stream में होगा)। हालांकि, NLog का यह अनुकूलन इस तथ्य के साथ फीका है कि आपको डेटा को फ़ाइल में रीसेट करना है।

कोटलिन का उदाहरण

.Net में लोकप्रिय लॉगर के काम के विवरण को पतला करने के लिए, मैं कॉललिन में कॉल लपेटने का एक दिलचस्प तरीका दूंगा। यह विचार वस्तुतः भाषा की एक दिलचस्प विशेषता पर आधारित है: इनलाइन विधियाँ । तो, डिबग करने के लिए कुछ उत्पादन करने के लिए एक सरल कोड:

 class SomeService{ private companion object : KLogging() fun publishData(id: Int){ logger.debug { "Identity: $id" } } } 

और इसे कंपाइलर द्वारा कुछ इस तरह से परिवर्तित किया जाएगा:

 class SomeService{ private companion object : KLogging() fun publishData(id: Int){ if(logger.isDebugEnabled){ try{ val message = "Identity: $id" logger.debug(message) }catch (e: Exception){ /*handle*/ } } } } 

यह यहाँ महत्वपूर्ण है: debug पास ब्रेसिज़ के अंदर सब कुछ एक लैम्ब्डा है। हालांकि, यह आपकी विधि में एम्बेडेड होगा, अर्थात, एक फ़ंक्शन ऑब्जेक्ट हीप में नहीं बनाया जाएगा। इस प्रकार, आप बड़े ऑपरेशन को अंदर छिपा सकते हैं, जिसे केवल तभी कहा जाएगा जब आप परिणाम को debug करना चाहते हैं। उदाहरण के लिए:

 class SomeService{ private companion object : KLogging() fun publishData(id: Int){ logger.debug { val idList = getIdList() "Identity: $idList" } } } 

यहां getIdList को केवल तभी कॉल किया जाएगा जब आपको फ़ाइल में कुछ भेजने की आवश्यकता होगी। और सभी क्योंकि कोड में परिवर्तित किया गया है:

 class SomeService{ private companion object : KLogging() fun publishData(id: Int){ if(logger.isDebugEnabled){ try{ val idList = getIdList() val message = "Identity: $idList" logger.debug(message) }catch (){ /*handle*/ } } logger.debug { "Identity: $id" } } } 

बड़ी वस्तु ==> बड़ी वस्तु ढेर

पिछले उदाहरण के अलावा। मुझे यकीन है कि बहुत से लोग जानते हैं कि .नेट / जेवीएम में "लार्ज ऑब्जेक्ट हीप" की अवधारणा है। अधिक सटीक रूप से, जावा में कोई विशेष परिभाषा नहीं है, हालांकि, आवंटनकर्ता अक्सर नवीनतम पीढ़ी में तुरंत बड़ी वस्तुओं का निर्माण करेंगे (वस्तुओं की आवाजाही को कम करने और एक स्ट्रीमिंग आवंटनकर्ता के लिए तेज मेमोरी पैठ की समस्या का स्तर)।

वापस उदाहरण के लिए:

 NLogLog.Debug($"Id={id}"); 

जैसा कि आप समझते हैं, अगर id ऑब्जेक्ट में ToString कार्यान्वयन होता है, जो मेगाबाइट के आकार को एक स्ट्रिंग बनाता है, तो LOH चेहरे में निम्नलिखित हिट होते हैं:

• खुद को बुलाने के लिए
• $"Id={id}" फ़ॉर्मेट करना
• और अगर लकड़हारे के डेवलपर्स ने इन सभी चीजों को नहीं पकड़ा (और एलओएच में वस्तुओं की अनुपस्थिति के लिए एक परीक्षण लिखना बेहद मुश्किल है), तो लकड़हारा समस्याओं को जोड़ देगा।

और यहां आप ऐसी चीजों को लॉग करने के तीन तरीकों का उपयोग कर सकते हैं:

• एक विशेष लेआउट का उपयोग करें और ToString कॉल की आवश्यकता नहीं है। उदाहरण के लिए, NLog में एक JsonLayout है । इस प्रकार, आप बस किसी ऑब्जेक्ट को लकड़हारे के पास स्थानांतरित कर सकते हैं, जिसे परिणामस्वरूप स्ट्रीम (उदाहरण के लिए, एक फ़ाइल पर) को तुरंत सीरियल किया जाएगा।
• फाइल को खुद लिखें। या दूसरे शब्दों में - लकड़हारे का उपयोग न करें। मैं केवल अपने दम पर सलाह दे सकता हूं कि कैसे पता लगाया जाए कि कौन सी फाइल एनएलओजी को लिखी जाएगी: var filePath = NLog.LogManager.Configuration.AllTargets.OfType<FileTarget>().First().FileName.Render(LogEventInfo.CreateNullEvent()) । जाहिर है, यह फ़ंक्शन पहले आने वाले पहले FileTarget को लौटा देगा, लेकिन अगर हर कोई एक ही फ़ोल्डर में लिखता है, तो इसी तरह से आप रिकॉर्डिंग के लिए फ़ोल्डर का पता लगा सकते हैं, और फिर सीधे फ़ाइल पर अपनी वस्तु का एक डंप भेज सकते हैं।
• यदि आपके पास log4j2 (दूसरा वाला महत्वपूर्ण है), तो आप StringBuilderFormattable का उपयोग कर सकते हैं। यह सिर्फ लकड़हारा को टुकड़ों में (आउटपुट के रूप में डेटा को आउटपुट करने के लिए बनाया गया था, ताकि ढेर के कुछ हिस्सों को आवंटित न किया जा सके, क्योंकि वे पहले से ही चुने गए हैं)।

 public interface StringBuilderFormattable { /** * Writes a text representation of this object into the specified {@code StringBuilder}, ideally without allocating * temporary objects. * * @param buffer the StringBuilder to write into */ void formatTo(StringBuilder buffer); } 

सिंक्रोनसिटी (और अतुल्यकालिक समस्याएं)

एक बार, एक कार्यक्रम में, मैंने देखा कि लोड किए गए ऑपरेशनों के दौरान, लॉगिंग ऑपरेशनों के बारे में आधे यूआई प्रतीक्षा समय का हिसाब था। एक बार फिर: प्रोग्रामर का आधा समय logger.Debug को कॉल करने पर खर्च किया गया। और इसका कारण सरल है: हमने log4net का उपयोग किया, जो केवल तुल्यकालिक रूप से फाइलें लिख सकता है।

यहाँ से मैंने नियम 1 को घटा दिया: लकड़हारे को हमेशा दूसरे धागे में काम करना चाहिए। आपको निशान के लिए आवेदन कोड को ब्लॉक नहीं करना चाहिए, क्योंकि यह अविश्वसनीय रूप से अजीब है। दूसरे शब्दों में - NLog का उपयोग करते हुए - आपको हमेशा nlog टैग (यह मुख्य है) में async=true nlog । या, जैसा कि उदाहरण कहता है:

 <targets async="true"> ... your targets go here ... </targets> 

यदि आप log4net का उपयोग करते हैं, तो या तो इसे NLog में रीडायरेक्ट करें, या AsyncFileAppender बनाएं।

जावा दुनिया के लिए: लॉगबैक और लॉग 4 जे 2 दोनों में एसिंक्रोनस लॉगिंग करने की क्षमता है। यहाँ आधिकारिक साइट से एक तुलना है:

हालांकि, जब सब कुछ अतुल्यकालिक रूप से लिखा जाता है, तो एक और समस्या उत्पन्न होती है - महत्वपूर्ण त्रुटियों के मामले में क्या करना है? आखिरकार, ऐसा होता है कि कोई प्रोग्राम बाहर नहीं निकलता क्योंकि उसने Main थ्रेड छोड़ दिया है (उदाहरण के लिए, एक प्रोग्राम Application.Exit या Environment.FailFast को कॉल करके बाहर निकल सकता है, जो बहुत सुंदर नहीं है, लेकिन ऐसा होता है)। इस मामले में, आपको अपनी प्रक्रिया को मारने से पहले हमेशा Flush कॉल करना होगा। अन्यथा, यदि आप युद्ध सर्वर पर आते हैं, तो सबसे मूल्यवान जानकारी छूट जाएगी।

निष्कर्ष

मुझे उम्मीद है कि यह लेख आपको सुविधाजनक लॉगिंग के साथ तेज कार्यक्रम लिखने में मदद करता है। मैंने उन समस्याओं के केवल एक हिस्से पर प्रकाश डाला, जिन्हें मैं कोड में देखता हूं। उनमें से सभी सबसे स्पष्ट नहीं हैं, लेकिन सबसे कठिन नहीं है।

किसी भी मामले में, जैसा कि मैंने शुरुआत में कहा, लॉगर के साथ काम करना लगभग हर एप्लिकेशन में है। इसके अलावा, मेरे नोट्स के अनुसार, लगभग आधे वर्ग स्वयं लॉग के लिए कुछ का उत्पादन करते हैं। इस प्रकार, इन कार्यों के साथ सही संचालन लगभग संपूर्ण अनुप्रयोग को प्रभावित करता है।