Вход стратегии по сравнению с производительностью
Я разрабатываю веб-приложение, которое должно поддерживать много одновременных запросов, и я хотел бы сохранить его достаточно быстро. Я должен теперь реализовать регистрирующуюся стратегию, я собираюсь использовать log4net, но... какой и как я должен зарегистрироваться? Я имею в виду:
- Как вход влияния в производительности? это - possible/recomendable, регистрирующийся использующий асинхронные вызовы?
- Действительно ли лучшее использование является текстовым файлом или базой данных? Действительно ли возможно сделать это условное выражение? например, значение по умолчанию регистрируются к базе данных, и если это перестало работать, переключатель к текстовому файлу.
- Что относительно многопоточности? я должен заботиться о синхронизации, когда я использую log4net? или это ориентировано на многопотоковое исполнение из поля?
В требованиях появляются, что приложение должно кэшировать несколько вещей на запрос, и я боюсь влияния производительности этого.
Удачи.
3 ответа
- Это замедляет работу - выполнение чего-либо требует больше времени, чем бездействие. Обычно на ничтожную сумму. Не беспокойся об этом.
- Войти в текстовый файл imo. Их легко перемещать / grep / compress / mail и т. Д., И вам не нужно беспокоиться о регистрации в базе данных того факта, что база данных не работает. Есть приложения для входа в базу данных для log4net, если вам это нужно.
- Да , log4net потокобезопасен.
Ведение журнала / трассировка чрезвычайно ценно - по крайней мере, вы должны регистрировать ошибки, иначе вы никогда не узнаете о них. Большинство API ведения журналов позволяют включать и отключать необходимый уровень детализации.
Не беспокойтесь о производительности, пока она не станет проблемой. Это не похоже на то, что вы строите лунные ракеты и хотите увидеть, какой вес они могут нести, тестируя их - это просто код, удаление операторов регистрации, которые заполняют ваши журналы, и перекомпиляция, если это когда-либо станет проблемой.
Я бы сказал, что вы беспокоитесь о производительности на ранних этапах работы, используйте log4net таким образом, чтобы его было очень легко отключить позже или настроить (например, : использование файла conf, который определяет уровень журнала NONE, ERROR, WARN, DEBUG, INFO, ALL, VERBOSE и т.д ...),
Однако ваши две другие проблемы верны, для вопроса 2 я бы выбрал простой файл как их можно легко прочитать и получить к ним доступ, в отличие от базы данных. Также производительность записи в конец файла лучше, чем в db.
И да, как утверждает nos, log4net является потокобезопасным.
Один общий совет: если ваш проект большой, и вы хотите иметь хоть какую-то надежду на то, что когда-либо у вас будут настраиваемые уровни журнала, как я описал выше, тогда вам действительно нужно согласовать стандарт кодирования в вашей команде о том, что регистрировать. на разных уровнях.
Я полностью согласен с тем, что сказали hhafez и nos. Вы идете по правильному пути, используя пакет протоколирования вместо того, чтобы пытаться создать свой собственный. Это намного чище и легче сделать правильно. Вести журнал в текстовый файл гораздо проще в долгосрочной перспективе (учитывая типичные навыки проекта), чем вести журнал в БД, хотя если вы планируете какой-либо сложный анализ данных, иногда проще просто иметь их уже в БД.
Если отладка является одной из заявленных целей внедрения решения для протоколирования, то крайне важно заранее стандартизировать все уровни протоколирования и сделать это частью процесса анализа кода. Различия в гранулярности должны быть достаточными, чтобы вы могли постепенно увеличивать глубину отчетов, переходя на следующий уровень. Очень неприятно, когда вы устраняете проблему PROD, не имеете достаточно информации из журнала, чтобы увидеть проблему, а затем переходите на следующий уровень регистрации и полностью заваливаете журналы таким количеством выделений, что не можете увидеть лес за деревьями (и ваши журналы прокручиваются каждые 5 минут из-за объема). Я видел, как это происходит.
В большинстве случаев протоколирования текстовых файлов производительность не должна быть проблемой. С логированием в БД все немного сложнее. Выполнение вставки лишь немного интенсивнее, чем добавление в текстовый файл, но именно объем на единицу времени делает это гораздо более уродливым в масштабе.
Кроме того, если вы собираетесь проводить автономный анализ журнала, вам следует выбрать такой формат файла журнала, который легко расширяется и не требует огромных изменений в коде анализа, если вам нужно что-то добавить в журнал. Держитесь подальше от вложенных, многокомпонентных структур сообщений. Их разбор превращается в мучение.
Удачи!