Стратегия ведения журнала и производительность

Question

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

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

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

Приветствие.

Answer 1

1. Это делает вещи медленнее - делать что-то занимает больше времени, чем ничего не делать. Обычно незначительным количеством. Не беспокойся об этом.
2. Вход в текстовый файл IMO. Их легко перемещать / grep / compress / mail и т. Д., И вам не нужно беспокоиться о входе в базу данных, потому что база данных не работает. Есть приложения для входа в базу данных для log4net, если вам это нужно.
3. Да , log4net является поточно-ориентированным.

Наличие регистрации / трассировки чрезвычайно ценно - по крайней мере, вы должны регистрировать ошибки, иначе вы никогда не узнаете о них. Большинство журналов API позволяют вам включать и выключать уровень детализации, который вам нужен.

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

Answer 2

Я бы сказал, что вы беспокоитесь о производительности на начальном этапе, используйте log4net таким способом, который очень легко отключить позже или настройте (например: используйте файл conf, который определяет уровень журнала NONE, ERROR, WARN, DEBUG, INFO, ALL, VERBOSE и т.д ...),

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

И да, поскольку nos заявил, что log4net является потокобезопасным.

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

Answer 3

Я полностью согласен с тем, что сказал Ххафез и Нос. Вы идете по правильному пути с пакетом регистрации, а не пытаетесь свернуть свой собственный. Это намного чище и легче получить права. Ведение журнала в текстовом файле намного проще для управления в долгосрочной перспективе (с учетом типичных наборов навыков проекта), чем ведение журнала в БД, хотя, если вы планируете какой-либо сложный анализ сообщаемых данных, иногда проще просто иметь его уже в БД.

Если отладка является одной из ваших заявленных целей при внедрении решения для ведения журналов, то крайне важно, чтобы вы заранее стандартизировали все уровни журналирования и включили эту часть в процесс проверки кода. Имейте достаточно различий в гранулярности, чтобы вы могли постепенно увеличить глубину отчетности, перейдя на следующий уровень. Очень неприятно, если вы решаете проблему с проблемой PROD, не имеете достаточного количества информации в журнале, чтобы увидеть проблему, затем переходите на следующий уровень ведения журнала и полностью забиваете журналы с таким большим выбросом, что вы не можете видеть лес за деревьями (и ваши логи катятся каждые 5 минут из-за громкости). Я видел, как это произошло.

В большинстве случаев регистрации текстовых файлов производительность не должна быть проблемой. Это немного сложнее с журналированием БД. Выполнение вставки является лишь немного более интенсивным, чем добавление к текстовому файлу, но именно объем на единицу времени делает его гораздо более уродливым в масштабе.

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

Удачи с этим!