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

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

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

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

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

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

Ответ 1

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

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

Ответ 2

log4net отправит трассировку на sql-db с целым кучей флеш-параметров и т.д. проверьте его: http://logging.apache.org/log4net/release/features.html

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

Ответ 3

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

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