высокоскоростное ведение журнала с использованием log4net - PullRequest
Новая
       21

высокоскоростное ведение журнала с использованием log4net

1 голос
/ 23 октября 2009

Меня интересует очень высокая скорость регистрации в log4net (около 10K сообщений в секунду). С этой целью я подумал о реализации следующих модулей:

  1. Макет протокола на основе буфера (IRawlayout) - для превосходной производительности сериализации
  2. приложение совместно используемой памяти и плагин - для уменьшения IPC между приложением регистрации и сервером регистрации.

это способ интеграции этих технологий?

Я также подумал об использовании ETW в log4net, но они кажутся слишком разными, чтобы быть элегантно интегрированными.

Ответы [ 2 ]

1 голос
/ 26 октября 2009

Я однажды посмотрел на google protobuffer и пришел к выводу, что это не будет такой большой помощью при регистрации, как кажется на первый взгляд. В ведении журнала много текста, который везде одинаков. Таким образом, переносимость протобуферов не является преимуществом. Что касается скорости, я также не уверен, что вам все равно придется передавать тот же текст по проводам на сервер, либо упакованный в пакет протобуфера, либо помеченный xml. Это, конечно, актуально, если вы регистрируете текстовую информацию. В случае двоичного журналирования это, вероятно, было бы круто сделать, хотя.

0 голосов
/ 13 января 2019

Некоторое время назад я провел исследование производительности log4net и создал пост в блоге

Вы можете найти там несколько приложений асинхронной пересылки log4net:

  1. Асинхронное решение log4net 1: BlockingCollection
  2. Асинхронное решение log4net 2: Метод горячей замены
  3. Асинхронное решение log4net 3: .NET-порт LMAX Disruptor

Результаты производительности асинхронных решений log4net с RollingFileAppender :

enter image description here enter image description here enter image description here

И некоторые мои замечания о производительности log4net:

  • AsyncForwardingAppenderBlocking Решение на основе BlockingCollection работает очень плохо, особенно для нескольких производителей журналов.
  • AsyncForwardingAppenderHotSwap решение, основанное на методе горячей замены обеспечивает лучшее ! Однако это может потребовать дополнительной памяти и даже вызывает исключение OutOfMemoryException, когда события журнала создаются очень быстро!
  • Решение AsyncForwardingAppenderDisruptor на основе порта .NET LMAX Disruptor работает хорошо, но все еще далеко от log4j2 даже с NullAppender. Рекомендуется изучить возможные проблемы с производительностью в disruptor-net или ее неправильное использование для случая регистрации.
...