Последовательное логирование в отдельном потоке

Последовательное логирование в отдельном потоке
Atom
2/17/2013
VassilSanych


Ещё одна доработка исходников:
Разгрузка основного потока от логирования.
Возможность изоляции от системных ресурсов, связанных с логированием.

Кстати, можно что-то придумать и для затыкания LoggingHelper.Now.
Потому что привязка кода к ресурсам системного времени - это совсем не TDD.
--------------------------------------
Критика просто жизненно необходима :)

PS
Беда какая-то с описанием темы. Ломается.

Tags:


Thanks:


1 2  >
Mikhail Sukhov

Avatar
Date: 2/17/2013
Reply


VassilSanych
Критика просто жизненно необходима :)


Начнем с того, что обычно формулируют проблему (типа как перед чтением стихов произносят название произведения и автора). Как решалась проблема?

Для примера. Я выделял логирование в отдельный поток, чтобы разгрузить основной поток торговли. Была проблема с перформансом логирования в файл, была решена с помощью параллельного потока.
Thanks:

VassilSanych

Avatar
Date: 2/17/2013
Reply


Логирование включает файловые и другие системные операции.
Это в любом случае замедляет выполнение основных алгоритмов.
При том, что логирование - операция как раз совершенно не критичная к времени запуска, в отличие от торговых операций.
Это не решение проблемы, это - архитектурная плюшка (о чём и сказано в комментарии темы).
PS
Должно было быть указано, но почему-то не было. Исправил :)
Thanks:

ra81

Avatar
Date: 2/17/2013
Reply


Да и вообще была проблема того что блокирование потока логов приводило к блокированию всей системы. :). С такой плюшкой думаю сего не повторится.
Thanks:

Mikhail Sukhov

Avatar
Date: 2/17/2013
Reply


VassilSanych
Логирование включает файловые и другие системные операции.
Это в любом случае замедляет выполнение основных алгоритмов.
При том, что логирование - операция как раз совершенно не критичная к времени запуска, в отличие от торговых операций.
Это не решение проблемы, это - архитектурная плюшка (о чём и сказано в комментарии темы).
PS
Должно было быть указано, но почему-то не было. Исправил :)


Так ведь сейчас уже в 4.1 логирование отделено от основного потока.
Thanks:

VassilSanych

Avatar
Date: 2/17/2013
Reply


Mikhail Sukhov
Так ведь сейчас уже в 4.1 логирование отделено от основного потока.

Где?
Я не нашёл.

Thanks:

Mikhail Sukhov

Avatar
Date: 2/17/2013
Reply


VassilSanych
Mikhail Sukhov
Так ведь сейчас уже в 4.1 логирование отделено от основного потока.

Где?
Я не нашёл.



LogManager.cs Это к слову о важности взаимодействия.
Thanks:

VassilSanych

Avatar
Date: 2/17/2013
Reply


Ага. Понял. Пишет пачками по таймеру (вспомнил, почему у меня пропадало сообщение о завершении работы).
И всё-таки лочит основной поток при добавлении сообщения в список.
Очередь была бы производительнее.
Thanks:

VassilSanych

Avatar
Date: 2/18/2013
Reply


Кстати.
У LogManager есть такой косяк:
когда количество сообщений превышает заданный максимум (т.е. как раз когда система очень сильно нагружена), логирование запускается в потоке вызова.
LogManager.cs 5 KB (219)
Thanks:

VassilSanych

Avatar
Date: 2/18/2013
Reply


Изменил буфер сообщений на конкурентную очередь, убрал все локи, принудительный запуск логирования заменил перещёлкиванием таймера.
Последнее исправление не тестировал.
Thanks:

pyhta4og

Avatar
Date: 2/18/2013
Reply


VassilSanych
Кстати.
У LogManager есть такой косяк:
когда количество сообщений превышает заданный максимум (т.е. как раз когда система очень сильно нагружена), логирование запускается в потоке вызова.



Это было сделано для того, чтобы очередь не отжирала всю память.

Помимо этого есть режим MaxMessages=-1 когда логирование идет синхронно. Это сделано для того чтобы производить отладку. Иначе получится что вы уже на бреакпойнт в коде робота встали, а логи еще в файл не записались.
Thanks:
1 2  >

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy