Сравнение производительности для входа к MSMQ / текстовый файл / база данных
У нас есть несколько вариантов для входа в систему нашей.NET (C#) серверное приложение. Мы собираемся пользоваться Библиотекой Предприятия. Таким образом, вот способы пойти:
1) Запись журнала к MSMQ синхронно, затем читая MSMQ с Сервисом Победы. Очередь находится на локальной машине для серверного приложения.
2) Запись журнала к диску (т.е. прокрутка текстовых файлов) синхронно.
3) Запись журнала к базе данных (Oracle, в нашем приложении) синхронно.
Количество журнала могло бы быть довольно большим. Таким образом, какой является самым производительным? Я предполагаю, что упорядочивание равняется 1, 2, 3.Я прав? Есть ли какой-либо другой показатель производительности, помимо скорости записи, в этом определенном сценарии? Есть ли какой-либо другой выбор, на который я не указал здесь, который мог бы быть более лучше путь?
3 ответа
Не слыша потребностей приложения в плане логирования:
У меня такое чувство, что сценарий логирования MSMQ - это немного большой молоток для решения проблемы.
MSMQ определенно будет быстрее, поскольку ваше приложение будет использовать протокол сетевого взаимодействия вместо того, чтобы иметь дело с задержкой на диске и созданием и разрывом соединения с БД. Однако, учитывая, что MSMQ использует диск, выигрыш, скорее всего, будет незначительным. Тогда вопрос в том, находится ли целевая/конечная очередь MSMQ на локальной машине.
Придерживайтесь протоколирования на диске
Рассмотрите возможность придерживаться протоколирования в файл на диске с соответствующими переносами (день/час по мере необходимости). Есть некоторые обходные пути, если вас СУПЕР волнует скорость вращения шпинделя - рассмотрите возможность записи файлов журнала на RAM-диск. Затем создайте процесс, который будет периодически копировать эти файлы из оперативной памяти на диск по мере необходимости.
Измерьте свои потребности в производительности журнала
Заканчивайте шутки о преждевременной оптимизации. Измеряйте, и еще раз измеряйте. Вы просто не будете знать, что вам нужно, пока не оцените, насколько хорошо работает ваше решение. Подумайте о том, что у вас, скорее всего, 10 000 об/мин шпинделей, и, вероятно, дисковое решение для протоколирования будет работать адекватно. Немного YAGNI может закрасться в голову, если решение будет принято в пользу сложного решения "аутсорсингового" компонента, такого как MSMQ или запись в базу данных. Я говорю это с учетом ваших заявленных потребностей в скорости.
Я думаю, вам следует рассмотреть " Асинхронно записывать журнал в базу данных ». то есть для каждого элемента, который вы хотите зарегистрировать, поставить его в очередь в памяти и иметь отдельный поток, записывающий в базу данных. Нет смысла держать основное приложение в ожидании завершения записи в журнал при условии, что порядок сообщений журнала поддерживается механизмом очереди.
Вы также смотрели log4net? Он включает в себя множество опций журналирования, включая мощный ротационный журнал на диск, ведение журнала UDP, ....
Вы также можете посмотреть на Splunk как на способ поиска файлов журналов после их создания.
Вы ранжирование MSMQ, файлов и БД должно быть правильным в типичных ситуациях.
Я знаю, что вас беспокоит производительность, но мне еще не приходилось сталкиваться со сценарием в бизнес-приложении, в котором я сожалел бы об используемом механизме регистрации. По сравнению с временем, затраченным на выполнение бизнес-логики, время, затраченное на ведение журнала, было не просто значительным.
Кроме того, если вас действительно беспокоит производительность, вы можете изучить другие варианты, помимо Enterprise Library. например log4net исторически работает быстрее.
Помимо производительности, я бы также рассмотрел другие требования. например Вам нужно сообщить или запросить журналы? Требуется ли вам центральное хранилище журналов (или было бы полезно)? Если ответ на любой из этих вопросов утвердительный, то вы, вероятно, захотите использовать базу данных или MSMQ, подающий базу данных.
Другими соображениями могут быть существующие реализации или стандарты, общая сложность решения (файл MSMQ>), возможность поддержки различных вариантов (например, вы можете не захотеть использовать MSMQ, если нет опыта эксплуатации).