Сравнение производительности для регистрации в MSMQ / текстовый файл / базу данных

Question

У нас есть несколько вариантов входа в наше серверное приложение .NET (C #). Мы собираемся использовать Enterprise Library. Итак, вот пути:

1) Синхронная запись журнала в MSMQ, затем чтение MSMQ с помощью Win Service. Очередь находится на локальном компьютере для серверного приложения.
2) Синхронная запись журнала на диск (т.е. прокатка текстовых файлов).
3) Запись журнала в базу данных (Oracle, в нашем приложении) синхронно.

Количество журналов может быть довольно большим. Итак, какой из них самый производительный? Я предполагаю, что порядок составляет 1, 2, 3. Я прав? Есть ли какой-либо другой фактор производительности, кроме скорости записи, в этом конкретном сценарии? Есть ли другие варианты, которые я здесь не указал, которые могли бы быть лучше?

Answer 1

Не слыша о потребностях приложения с точки зрения ведения журнала:

У меня такое ощущение, что сценарий ведения журнала MSMQ - это большой удар по проблеме.

MSMQ определенно будет быстрее, поскольку ваше приложение будет использовать сетевой протокол связи вместо того, чтобы иметь дело с задержкой диска и созданием и разрывом соединения с БД.Однако, учитывая, что MSMQ использует диск, выигрыш, вероятно, незначителен.Тогда возникает вопрос, находится ли эта очередь назначения / назначения MSMQ на локальном компьютере.

Придерживайтесь ведения журнала на диске

Попробуйте придерживаться записи в файл на диске с соответствующими ролловерами (день / час по мере необходимости).Есть некоторые обходные пути, если вы СУПЕР заботитесь о скорости шпинделя - рассмотрите возможность записи этих файлов журнала на RAM-диск.Затем начните процесс копирования этих файлов из оперативной памяти на диск периодически по своему усмотрению.

Измерение потребностей в производительности ведения журналов

Подсказки о преждевременной оптимизации.Мера, и мера снова.Вы просто не будете знать, что вам нужно, пока не оцените, насколько хорошо работает ваше решение.Предположим, что у вас, вероятно, есть 10 000 оборотов в минуту, и, вероятно, решение для ведения журнала диска будет работать адекватно.Немного YAGNI может закрасться, если будет принято решение перейти к сложному решению «внешнего» компонента, такого как MSMQ или запись в базу данных.Я говорю это с вашими заявленными потребностями вокруг скорости.

Answer 2

Ваш рейтинг MSMQ, File и DB должен быть правильным в типичных ситуациях.

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

Кроме того, если вы действительно обеспокоены производительностью, вы можете изучить другие варианты, кроме Enterprise Library. например Исторически log4net работал быстрее.

Помимо производительности, я бы также рассмотрел другие требования. например Вам нужно сообщить или запросить в журналах? Вам нужен центральный репозиторий журналов (или это будет полезно)? Если ответ на любой из этих вопросов - «да», то вы, вероятно, захотите использовать базу данных или MSMQ, подпитывающую базу данных.

Другими соображениями могут быть существующие реализации или стандарты, общая сложность решения (файл MSMQ>), поддержка различных вариантов (например, вы можете не захотеть использовать MSMQ, если нет опыта работы).

Answer 3

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

Кроме того, вы смотрели на log4net? Он включает в себя множество параметров ведения журнала, в том числе мощный вращающийся журнал на диск, протоколирование UDP, ....

Возможно, вы захотите взглянуть на Splunk как на способ поиска файлов журналов после их создания.