Какое влияние на производительность оказывает трассировка в C # и ASP.NET?

Question

Я нашел это в каком-то рабочем логине, который я недавно искал ...

HttpContext.Current.Trace.Write(query + ": " + username + ", " + password));

... где query - это короткий SQL-запрос для захвата соответствующих пользователей. Влияет ли это на производительность? Я предполагаю, что это очень маленький.

Кроме того, какова цель этого точного типа трассировки с использованием HTTP-контекста? Откуда эти данные отслеживаются? Заранее спасибо!

Answer 1

Да, это будет влиять на производительность всякий раз, когда во время сборки определяется константа условной компиляции TRACE. Делать что-либо оказывает влияние:)

Относительно того, оказывает ли это существенное влияние на приложение. Маловероятно, что это произойдет, так как Trace предназначен для работы и запускается во многих производственных приложениях. Только злоупотребление этой функцией должно привести к заметной разнице в производительности.

Но, как всегда, не верь мне, доверься профилировщику.

Answer 2

У меня пока нет очков репутации за комментарии, но я хотел сделать быстрое заявление об ответе Джонатана. Похоже, числа, которые я видел, показывают, что не имеет смысла использовать stringbuilder для нескольких конкатенаций строк. Затраты на создание объекта stringbuilder перевешивают выигрыш в скорости объединения.

Answer 3

Наибольшая потеря производительности в этом фрагменте кода заключается не в трассировке, а в конкатенации строк при использовании оператора +. Это делает некоторые неэффективные операции с памятью, которые могут превзойти операцию ввода-вывода с точки зрения производительности. Я бы изменил его, чтобы использовать что-то вроде string.Concat или класс StringBuilder (или в этом случае string.Format).

Answer 4

Сообщения трассировки могут отправляться во множество разных мест. Вы можете добавить (или удалить) TraceListener для консоли, окна отладки VisualStudio, файлов или журнала событий, чтобы назвать несколько. Вы даже можете построить свой собственный.

Кроме того, вы можете настроить Trace так, чтобы он ничего не делал при компиляции для Release.

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

Answer 5

"Трассировка добавляет дополнительные издержки к запросам и не должна быть включена для развернутых приложений. Однако операторы Trace.Write () можно оставить, поскольку они игнорируются, когда трассировка не включена."

http://msdn.microsoft.com/en-us/library/ms972204.aspx

Answer 6

Полагаю, Trace Source просматривает TraceLevel своего коммутатора, прежде чем пересылать сообщения слушателям. Таким образом, если мы оставим значение TraceLevel по умолчанию для коммутатора равным «Error», тогда издержки трассировки будут значительно уменьшены, поскольку только слушатели «Error» будут отправлять слушателям.

просто предположение ... я еще ничего не измерил. Буду обновлять, если я сделаю.

2017 Обновление : кажется устаревшим, но довольно удобным способом отслеживания / регистрации информации в браузере / на удаленно доступной странице .aspx в приложении asp.net.

https://msdn.microsoft.com/en-IN/library/z48bew18(v=vs.71).aspx

Answer 7

А если трассировка записывает в текстовый файл, это будет стоить дороже, чем запись в консоль IMHO