هل log4net أبطأ بكثير من System.Diagnostics.Trace؟

Question

أنا أتحقق من الاختلافات بين استخدام log4net و System.Diagnostics.Trace للتسجيل، وأنا مهتم بالاختلافات في الأداء التي لاحظتها.

لقد قمت بإنشاء تطبيق اختبار لمقارنة أداء كلتا طريقتي التسجيل في عدة سيناريوهات، ووجدت أن log4net أبطأ بشكل ملحوظ من Trace فصل.على سبيل المثال، في السيناريو الذي أقوم فيه بتسجيل 1000 رسالة بدون تنسيق سلسلة، يكون متوسط ​​وقت تنفيذ log4net لأكثر من 1000 تجربة هو 9.00 مللي ثانية. Trace ينفذ بمتوسط ​​1.13 مللي ثانية.تحتوي الكثير من حالات الاختبار الخاصة بي على قدر كبير نسبيًا من التباين في أوقات تنفيذ log4net؛يبدو أن الطبيعة الدورية لعمليات الإعدام الطويلة تشير إلى تدخل GC.يؤكد البحث باستخدام CLR Profiler على وجود عدد كبير من المجموعات مقابل الكثير log4net.Core.LoggingEvent الكائنات التي تم إنشاؤها (لكي نكون منصفين، يبدو Trace يولد طن من Char[] الكائنات أيضًا، ولكنها لا تعرض التباين الكبير الذي يعرضه log4net.)

شيء واحد أضعه في الاعتبار هنا هو أنه على الرغم من أن log4net يبدو أبطأ بحوالي 9 مرات من Trace, ، الفرق هو 8 مللي ثانية على 1000 تكرار؛هذا ليس بالضبط استنزافًا كبيرًا للأداء.ومع ذلك، قد تكون بعض حالات الاستخدام المتوقعة الخاصة بي هي استدعاء الأساليب التي تسجل الأشياء مئات الآلاف من المرات، وهذه الأرقام مأخوذة من جهازي السريع.على جهاز أبطأ أكثر نموذجية لتكوينات مستخدمينا، يكون الفرق من 170 مللي ثانية إلى 11 مللي ثانية وهو أمر أكثر إثارة للقلق قليلاً.

هل هذا الأداء نموذجي لـ log4net، أم أن هناك بعض الأخطاء التي يمكن أن تزيد بشكل كبير من أداء log4net؟

(ملحوظة:أدرك أن تنسيق السلسلة يمكن أن يغير وقت التنفيذ؛أحاول مقارنة التفاح بالتفاح ولدي حالات اختبار بدون تنسيق وحالات اختبار بالتنسيق؛يظل log4net بطيئًا نسبيًا سواء تم استخدام تنسيق السلسلة أم لا.)

القصة حتى الآن:

• لدى روبرت جولد أفضل إجابة لهذا السؤال؛كنت أشعر بالفضول بشكل أساسي إذا كان من المعتاد رؤية أداء log4net أبطأ بكثير من Trace فصل.
• إجابة Alex Shnayder هي معلومات مثيرة للاهتمام ولكنها لا تندرج في نطاق السؤال.نصف الهدف من تقديم هذا التسجيل هو المساعدة في تصحيح الأخطاء المنطقية ومشاكل الأداء على الأنظمة الحية؛يضع عملاؤنا منتجاتنا في العديد من السيناريوهات الغريبة التي غالبًا ما يصعب إعادة إنتاجها بدون تكوينات الأجهزة باهظة الثمن وواسعة النطاق.ما يقلقني الرئيسي هو أن الاختلاف الكبير في التوقيت بين "عدم التسجيل" و"تسجيل الدخول" يمكن أن يؤثر على النظام بطريقة تمنع حدوث أخطاء.في النهاية، حجم الانخفاض في الأداء كبير ولكن الحجم صغير، لذلك آمل ألا يكون هناك مشكلة.

Answer 1

نعم، log4xxx أبطأ من التتبع، نظرًا لأن التتبع عادةً ما يكون أداة قريبة من kernel، في حين أن log4xxx أداة أكثر قوة.أنا شخصياً أفضل log4xxx نظرًا لمرونته، ولكن إذا كنت تريد شيئًا لا يؤثر كثيرًا، ولا تحتاج حقًا إلى سجلات للإنتاج، على سبيل المثال، في تصحيح الأخطاء، يجب أن يكون التتبع فقط كافيًا.

ملحوظة:أستخدم log4xxx لأن الأمر نفسه ينطبق على جميع اللغات التي تحتوي على مكتبة log4 وليس فقط .Net

Answer 2

قد تكون مهتمًا بـ مكتبة Common.Logging.إنه عبارة عن غلاف تجريدي رفيع فوق تطبيقات التسجيل الحالية ويسمح لك بتوصيل أي إطار عمل تسجيل تريده في وقت التشغيل.كما أنه أسرع بكثير من System.Diagnostics.Trace كما هو موضح في ملفي مشاركة مدونة حول الأداء.

HTH ، إريك

Answer 3

من تجربتي، لا يمثل أداء log4net مشكلة في معظم الحالات.السؤال الحقيقي هو، لماذا تحتاج حتى إلى "تسجيل الأشياء مئات الآلاف من المرات" في نظام الإنتاج.
كما أرى، في الإنتاج، يجب عليك تسجيل الحد الأدنى فقط (المعلومات وقد تكون مستوى تحذير)، وفقط إذا لزم الأمر (تصحيح مشكلة في الموقع) يجب تنشيط تصحيح الأخطاء على مستوى التصحيح.

Answer 4

إذا كنت تريد الأفضل في كلا العالمين، فسيسمح لك log4net بتسجيل الدخول إلى برنامج تتبع aspnet أيضًا.أقوم بتشغيل هذا الخيار عندما أرغب في الحصول على إحصائيات الأداء المرتبطة بأحداث معينة في التسجيل الخاص بي.

Answer 5

لقد قمت للتو بإجراء اختبار لمقارنة الكتابة التسلسلية بملف بسيط مقارنة باستخدام Log4Net لنفس المهمة. Log4Net أبطأ بنحو 400 مرة مقارنة بـ StreamWriter.So أعتبر أن Log4Net غير قابل للاستخدام إذا كنت تكتب إلى ملفات تسجيل ضخمة.ولكن أجد ذلك مفيد جدًا للكميات الصغيرة من إدخالات السجل وتصحيح الأخطاء.

ربما يكون الحل لعزل تسجيل الدخول في موضوع منفصل في بعض الحالات.