Реализация пользовательского TraceListener в .NET - PullRequest
11 голосов
/ 22 февраля 2009

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

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

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

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

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

Ответы [ 3 ]

5 голосов
/ 23 февраля 2009

log4net сбросит трассировку в базу данных sql с целой кучей параметров сброса и т. Д. проверить это: http://logging.apache.org/log4net/release/features.html

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

4 голосов
/ 22 февраля 2009

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

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

1 голос
/ 24 февраля 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...