इस लेख में मैंने लकड़हारे की सबसे निजी कॉल के मानदंड रखे हैं। मैंने M4 SSD के साथ Intel Windows 10 x64 पर log4net और NLog पर सभी प्रयोग किए।

GitHub पर कच्चे परिणाम देखे जा सकते हैं। कोड समान रिपॉजिटरी में है (चलाने के लिए, आपको .Net 4.7.2 + Microsoft Visual Studio 2017+ की आवश्यकता होगी)।

क्या, कैसे और क्यों - कट के तहत।

लंबे समय तक नहीं पढ़ने के लिए, परिणाम तालिका:

NoOpLogging

पहले, आइए अनुमान लगाएं कि हम लॉगिंग के लिए एक विधि को कॉल करने में कितना समय बिताते हैं, जो अंत में कुछ भी नहीं होने वाला है। ज्यादातर मामलों में (मेरे अनुभव में) क्रिया डिबग लड़ाई सर्वर पर अक्षम है, लेकिन कोई भी कॉल को हटाता नहीं है।

सबसे पहले, परिणाम:

और कोड:

void Log4NetNoParams() => _log4Net.Debug("test"); void Log4NetSingleReferenceParam() => _log4Net.DebugFormat("test {0}", _stringArgument); void Log4NetSingleValueParam() => _log4Net.DebugFormat("test {0}", _intArgument); void Log4NetMultipleReferencesParam() => _log4Net.DebugFormat( "test {0} {1} {2} {3} {4} {5} {6} {7} {8}", _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument); void Log4NetMultipleValuesParam() => _log4Net.DebugFormat( "test {0} {1} {2} {3} {4} {5} {6} {7} {8}", _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument); void NLogNetNoParams() => _nlog.Debug("test"); void NLogNetSingleReferenceParam() => _nlog.Debug("test {0}", _stringArgument); void NLogNetSingleValueParam() => _nlog.Debug("test {0}", _intArgument); void NLogNetMultipleReferencesParam() => _nlog.Debug( "test {0} {1} {2} {3} {4} {5} {6} {7} {8}", _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument, _stringArgument); void NLogNetMultipleValuesParam() => _nlog.Debug( "test {0} {1} {2} {3} {4} {5} {6} {7} {8}", _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument, _intArgument); 

पहले, आइए निर्धारित करें कि इस तरह के परीक्षण क्यों चुने गए:

• प्रयोग सबसे लोकप्रिय पुस्तकालयों पर किए गए थे।

• NLog और log4net के पास कम संख्या में तर्क के लिए अलग-अलग फ़ंक्शन हस्ताक्षर हैं:

  
  
  • log4net:
  
  

   void DebugFormat(string format, object arg0) 

  
  
  • NLog:
  
  

   void Debug(string message, string argument) void Debug<TArgument>(string message, TArgument argument) 

  
  
  • सिद्धांत: जब एक महत्वपूर्ण प्रकार को log4net में स्थानांतरित किया जाता है, तो बॉक्सिंग होनी चाहिए, जो बस प्रोसेसर समय खर्च करता है और कुछ भी नहीं करता है। NLog के मामले में, ऐसा कोई व्यवहार नहीं है, इसलिए बाद वाले को तेजी से काम करना चाहिए।
  
  
• पुस्तकालयों में बड़ी संख्या में तर्कों के लिए हस्ताक्षर लगभग समान हैं, इसलिए मैं जानना चाहूंगा:
  
  • कम मापदंडों के साथ तरीकों को लागू करने के लिए यह कितना अधिक कुशल है।
  • क्या दो पुस्तकालयों के बीच "Is ... Enabled" पद्धति को कॉल करने की गति में अंतर है

और अब परिणामों का विश्लेषण:

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

FileLogging

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

परिणाम:

प्रयुक्त कोड:

• log4net:

 var roller = new RollingFileAppender(); roller.ImmediateFlush = true; roller.RollingStyle = RollingFileAppender.RollingMode.Once; roller.MaxFileSize = 128 * 1000 * 1000; 

• NLog:

 new FileTarget($"target_{_logIndex++}") { ArchiveAboveSize = 128 * 1000 * 1000, MaxArchiveFiles = 16, AutoFlush = true, ConcurrentWrites = false, KeepFileOpen = false }; 

जैसा कि आप देख सकते हैं, लॉगर्स का विन्यास कमोबेश समान है, और परिणामों के अनुसार:

• NLog लॉग 4net की तुलना में थोड़ा तेज है, कहीं 15% के आसपास है।
• परीक्षणों के अनुसार, यह पता चला कि कम मापदंडों को लॉग करना अधिक कुशल है। हालांकि, किसी को यह नहीं भूलना चाहिए कि बड़ी संख्या में मापदंडों के साथ, परिणामस्वरूप स्ट्रिंग का भी विस्तार हुआ। इसलिए, तालिका केवल Log4net के खिलाफ NLog की सही ढंग से तुलना करती है।

NLog - विभिन्न प्रकार के ताले

स्रोत कोड:

 new FileTarget($"target_{_logIndex++}") { ArchiveAboveSize = 128 * 1000 * 1000, MaxArchiveFiles = 16, AutoFlush = true, ConcurrentWrites = XXXXX, KeepFileOpen = YYYYY }; 

यदि हम XXXXX और YYYYY के स्थान पर सभी संभावित संयोजन डालते हैं, तो हमें तालिका से परीक्षण मिलता है।

परिणाम बहुत अनुमानित हैं:

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

अतुल्यकालिक लॉगिंग और विभिन्न लॉकिंग विधियां

एनएलओजी लाइब्रेरी भी एक और धागे पर सभी आईओ संचालन करने में सक्षम है, तुरंत वर्तमान को मुक्त करता है। और वह इसे सक्षम रूप से करता है, घटनाओं के क्रम को संरक्षित करता है, सभी डेटा को ब्लॉकों में छोड़ता है, और प्रत्येक ब्लॉक में एक पूर्णांक एक ईवेंट नंबर होता है (ताकि क्रॉप्ड लाइनें प्राप्त न हों), और इसी तरह।

विभिन्न गैर-अवरोधक विधियों के परिणाम:

अवरुद्ध और अतुल्यकालिक दृष्टिकोणों की तुलना आगे की जाएगी, लेकिन यहां - केवल अंतिम।

AsyncTargetWrapper कोड:

 new AsyncTargetWrapper(fileTargetWithConcurrentWritesAndCloseFileAsync) { OverflowAction = AsyncTargetWrapperOverflowAction.Block, QueueLimit = 10000 } 

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

निष्कर्ष:

• यदि एसिंक्रोनस आउटपुट का उपयोग किया जाता है, तो यह मायने नहीं रखता है कि फ़ाइल के साथ किस प्रकार की आउटपुट सेटिंग्स का उपयोग किया जाता है। आप हर बार फ़ाइल को खोल और बंद कर सकते हैं, एक बड़े बफर के साथ यह लगभग अगोचर होगा।
• सभी माप केवल उस स्थिति के लिए सही होते हैं जब डेटा को बफ़र्स के भरने के रूप में उसी गति से डिस्क में प्रवाहित किया जाता है (मैंने इसे तेजी से फाइल सिस्टम + माप के बीच प्राकृतिक ठहराव के कारण किया था)।

सिंक्रोनस और एसिंक्रोनस लॉगिंग

निष्कर्ष:

• तेज डिस्क के बावजूद (मेरे मामले में - M.2 SSD), एक फाइल को किसी अन्य स्ट्रीम में लिखने से कई बार काम की गति बढ़ जाती है। यदि आपका आवेदन एचडीडी डिस्क को लिखता है, और यहां तक ​​कि एक आभासी मशीन पर भी चलता है, तो लाभ और भी अधिक होगा।
• हालांकि, अतुल्यकालिक कोड के तेजी से संचालन के बावजूद, लॉगिंग की कमी एक और भी अधिक लाभ देती है (पुस्तकालय के आधार पर, थोड़ा अलग है)।

लकड़हारे पैदा करना

परिणाम:

क्या परीक्षण किया गया था:

 [Benchmark] public object CreateLog4NetFromString() { return LogManager.GetLogger("my-logger_" + (Interlocked.Increment(ref _log4NetStringLogIndex) % 1000)); } [Benchmark] public object CreateNLogFromString() { return NLog.LogManager.GetLogger("my-logger_" + (Interlocked.Increment(ref _nLogStringLogIndex) % 1000)); } [Benchmark] public object CreateLog4NetLogger() { return new [] { LogManager.GetLogger(typeof(BaseTest)), // x16 times }; } [Benchmark] public object CreateNLogTypeOfLogger() { return new[] { NLog.LogManager.GetCurrentClassLogger(typeof(BaseTest)), // x16 times }; } [Benchmark] public object CreateNLogDynamicLogger() { return new[] { NLog.LogManager.GetCurrentClassLogger(), // x16 times }; } 

महत्वपूर्ण टिप्पणी: दुर्भाग्य से, मेरे लिए एक प्रतिलिपि प्रस्तुत करने योग्य बेंचमार्क बनाना मुश्किल था, जो आउट ऑफ मेमोरी के लिए नेतृत्व नहीं करता था, लेकिन जो अलग-अलग लॉगर बनाता होगा (यानी विभिन्न प्रकारों के लिए, विभिन्न लाइनों के लिए और इसी तरह)।

हालांकि, पुस्तकालयों के काम का अध्ययन करने पर, मैंने पाया कि एक लकड़हारा कुंजी बनाने के लिए लगभग सबसे कठिन संचालन किया जाता है (यानी, एक नाम का निर्धारण, जेनेरिक तर्कों को साफ करना, और इसी तरह)।
इसके अलावा, log4net के लिए लकड़हारा बनाने के लिए बेंचमार्क को स्थिर करने के लिए, एक ऑपरेशन नहीं करना आवश्यक था, लेकिन 16 (यानी 16 समान वस्तुओं की एक सरणी वापस आ गई है)। यदि आप कुछ भी नहीं लौटाते हैं, तो .Net ने मेरे लिए निष्पादन को अनुकूलित कर दिया (जाहिर है, सिर्फ परिणाम नहीं लौटाया गया), जिसके कारण गलत परिणाम आए।

और निष्कर्ष:

• लॉगर सबसे जल्दी तार से बनाए जाते हैं (NLog फिर से तेज है, हालांकि, पुस्तकालयों के बीच का अंतर छोटा है, यह देखते हुए कि लॉगर न केवल उसी तरह बनाए जाते हैं, बल्कि उनके साथ बाद के काम के लिए)।
• Log4net NLog की तुलना में तेज़ है जब किसी प्रोजेक्ट को इनिशियलाइज़ करता है शायद यह NLog पक्ष पर अतिरिक्त कैशिंग के कारण है, जो Debug , Info आदि के लिए सीधे कॉल को गति देने में मदद करता है। वास्तव में, प्रत्येक ILogger को स्वयं ही उत्तर पता है: निम्न विधियों को कॉल करना है या नहीं (और इसके लिए सामान्य कॉन्फ़िगरेशन के लिए कम से कम किसी प्रकार के बंधन की आवश्यकता है)। इस कार्य योजना की वजह से, आउट ऑफ मेमोरी का उपयोग मेरे द्वारा अधिकांश परीक्षणों पर किया गया था (यदि मैं विभिन्न लाइनों का उपयोग करता हूं, आदि)।
• LogManager.GetCurrentClassLogger() LogManager.GetLogget(typeof(XXX)) की तुलना में भी धीमा है। यह तार्किक है, यहां तक ​​कि NLog डेवलपर्स पहले तरीके को लूप में कॉल करने की सलाह नहीं देते हैं।
• और सबसे महत्वपूर्ण बात: इन सभी तरीकों की गति अक्सर आवेदन की ठंडी शुरुआत को प्रभावित करती है जब फॉर्म के क्षेत्र private static readonly ILogger Log = LogManager.GetCurrentClassLogger() रूप से आसानी से private static readonly ILogger Log = LogManager.GetCurrentClassLogger() । यही है, यह सीधे सिस्टम के प्रदर्शन को प्रभावित नहीं करता है।

निष्कर्ष

लॉग्स को संभालने का सबसे अच्छा तरीका क्या है:

• यदि यह संभव नहीं है कि लॉग इन न करें, तो यह सबसे तेज़ होगा (जो अब तक स्पष्ट है)।
• यदि प्रोजेक्ट में कई लकड़हारा कॉल हैं जो डेटा को किसी फ़ाइल (कंसोल, आदि) पर डंप नहीं करते हैं, तो NLog तेज है। इसके अलावा, यह ढेर पर कम वस्तुओं को आवंटित करता है।
• यदि आपको अभी भी किसी फ़ाइल को लिखने की आवश्यकता है, तो NLog एसिंक्रोनस रूप से सबसे जल्दी काम करता है। हां, यह अधिक मेमोरी खाती है (तुल्यकालिक मोड में NLog की तुलना में, क्योंकि मेरे पिछले मापों के अनुसार, log4net सरणियों और Stream पुन: उपयोग की कोशिश भी नहीं करता है)। हालांकि, कार्यक्रम तेजी से चलाने में सक्षम होगा।
• एक लकड़हारा बनाना एक नि: शुल्क ऑपरेशन नहीं है, इसलिए अक्सर इसे स्थिर क्षेत्र के साथ बनाना बेहतर होता है। यह एक स्ट्रिंग से बनाने पर लागू नहीं होता है, LogManager.GetLogger("123") , LogManager.GetLogger("123") जैसा कुछ। इस तरह के कॉल तेजी से काम करते हैं, जिसका अर्थ है कि ऑब्जेक्ट्स के बड़े उदाहरणों के लिए एक लकड़हारा बनाया जा सकता है (उदाहरण के लिए, "क्वेरी के संदर्भ के लिए एक लकड़हारा")।
• यदि आप लॉग में बहुत सारे मापदंडों का उत्पादन करना चाहते हैं, लेकिन ज्यादातर मामलों में फ़ाइल में कोई सीधा डेटा डंप नहीं होगा, तो कई कॉल करना सबसे अच्छा है। इसलिए, एनप्लोग ढेर पर अतिरिक्त ऑब्जेक्ट नहीं बनाएंगे यदि उन्हें वहां ज़रूरत नहीं है।

आपके कोड के लिए निष्कर्ष:

• यदि आपका तरीका एक मनमानी वस्तु (यानी object ) को स्वीकार करता है और ज्यादातर मामलों में कुछ भी नहीं करता है (जो अनुबंधों / सत्यापनकर्ताओं के लिए सही है), तो यह सामान्य रूप में कॉल को लपेटने के लिए सबसे सही है (यानी फॉर्म के तरीके Something<TArg>(TArg arg) )। यह वास्तव में तेजी से काम करेगा।
• यदि आपके कोड में एक फ़ाइल डेटा रीसेट करने की अनुमति है और उसी समय किसी और चीज़ के साथ काम करते हैं, तो भ्रमित होना बेहतर है और इसका समर्थन करें। हां, यह स्पष्ट प्रतीत होता है कि समानांतर निष्पादन कार्य को गति दे सकता है, हालांकि, आईओ संचालन के मामले में, यह दृष्टिकोण धीमी डिस्क वाले मशीनों पर एक अतिरिक्त प्रदर्शन को बढ़ावा देता है।