Реализация пользовательского TraceListener в .NET

Question

Я ищу лучшие практики для реализации TraceListener, которые будут записывать журналы внутри SQL-сервера из приложения ASP.NET.

Каковы вещи, которые следует учитывать при внедрении такого класса, чтобы избежать снижения производительности?

Будут ли хранимые процедуры выполняться быстрее, чем простые инструкции ADO.NET INSERT?

Мне очень нравится идея записи журналов во временный буфер памяти и сброс его в базу данных в какой-то более поздней точке из фонового потока, но какая структура данных наиболее подходит для такого сценария? Queue<T> кажется хорошим кандидатом, но я не могу добавить в него элементы без какого-либо механизма синхронизации.

Я нашел через Интернет article, который показывает пример пользовательского TraceListener, который пишет на SQL-сервер, но перед тем, как поместить его в производственный код, я хотел бы получить еще несколько отзывов.

Answer 1

Сохраненные процедуры не будут быстрее, чем параметризованные SQL. Я предпочитаю хранимую процедуру над hardcoding SQL в своем приложении, но если вы собираетесь генерировать инструкции insert, это еще лучше.

Использование буфера - хорошая идея, если вы в порядке с идеей, что вы можете потерять данные. Если вы хотите отделить клиента от вставки и хотите, чтобы он был долговечным, вы можете использовать MSMQ. Затем вы можете написать службу Windows, которая будет обрабатывать очередь, и она будет полностью отделена от приложения. Он также может объединять журналы с нескольких серверов, если у вас есть ферма серверов.

Answer 2

log4net сбросит след в БД SQL с целой кучей флеш вариантов и т.д. проверить это: http://logging.apache.org/log4net/release/features.html

log4net доказана. если вы можете избежать «повторного написания колеса», это хорошо?

Answer 3

Я не могу говорить о том, быстрее ли SP быстрее, чем вставки ADO, но я всегда предлагаю хранить запросы/невостребования в вашем приложении, а не в хранилище данных. как вы сейчас, хранилище данных предназначено для данных, а не для логики. избегать СП.

MS SQL Server - сложный механизм, и я не думаю, что ваше приложение сможет вызвать блокировку вашего кода из-за слишком большого количества записей в вашем db. очевидно, что это зависит от вашей конкретной реализации и от вашего интереса к производительности, я могу предположить, что вы намерены поддерживать большой объем. что я говорю, я не думаю, что вам нужна очередь или служба в памяти, чтобы обернуть процесс ведения журнала. просто очистите трассировку до db в приложении aspnet и забудьте о кешировании/промывке. SQL будет следить за сохранением запросов журнала в памяти, и он будет следить за его записью на диск - на самом деле это прекрасно справляется с этим. Буфер запросов SQL гарантирует, что ваш код не будет блокироваться, когда вы сбросите трассировку. если вы не верите мне, проверьте его с отметками времени в окне отладки или что-то в этом роде. если вам нужно настроить его, настройка должна быть в настройках памяти вашего db. Вам не нужно изобретать обертку здесь, использовать SP или запускать другую службу на вашем сервере (например, MSMQ), это просто съест больше вашего драгоценного процессора и памяти.