Цель базы данных Nlog - использовать keepConnection или нет? - PullRequest
5 голосов
/ 22 марта 2012

Я использую NLog в приложении asp.net 2.0;он получает много трафика и регистрирует много данных (в среднем около 5000 записей в день) как для регистрации ошибок, так и для статистических целей.Он использует две разные цели базы данных, каждая из которых вызывает хранимую процедуру, и обе с одинаковой строкой соединения (SQL Server).

Скопировав определение цели из некоторой документации, обе цели имеют keepConnection установить в «истину», что, я знаю, по умолчанию.У меня вопрос: это желательно? Я часто вижу много открытых соединений, открытых NLog в базе данных (просматривая открытые процессы в мониторе активности), а также иногда получаю сбои соединений в NLog;У меня возникает соблазн попробовать отключить keepConnection, но я также обеспокоен большим количеством операций открытия и закрытия.Я не смотрел на исходный код и не уверен, что смогу ответить на свой вопрос в любом случае, поэтому я не уверен, как работает соединение относительно пула, в котором находится его родительское приложение.

Есть мысли, предупреждения или советы?Я знаю, что мой вопрос немного туманный - просто я не могу найти ничего, кроме простой документации этого атрибута, и хотел бы получить некоторые отзывы о плюсах и минусах - то есть, почему он был включен в NLog впервое место?Благодарю.

1 Ответ

2 голосов
/ 02 июля 2013

Традиционно keepConnection был включен из-за точной причины, которую вы указали, было бы ужасно быстро открывать / закрывать большое количество соединений. Если отключено, NLog откроет соединение, запишет отдельную запись в журнал и закроет каждое соединение.

Если вы хотите, чтобы соединения закрывались, вы всегда можете использовать оболочку для повышения производительности журналирования, записывая журналы партиями

Проверить асинхронный буфер: https://github.com/nlog/nlog/wiki/AsyncWrapper-target

Размер партии по умолчанию равен 100, что, вероятно, вам подходит. В этом случае было бы хорошо отключить keepConnection. При этом NLog помещает в очередь 100 сообщений журнала, а затем открывает соединение, записывает их все и затем закрывает соединение.

Кроме того, 5000 в день - это очень мало для ведения журнала, что составляет 4 журнала в минуту, что, конечно, не большая нагрузка. Похоже, что-то еще не так.

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

useTransactions=true

https://github.com/nlog/nlog/wiki/Database-target

...