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

StackOverflow https://stackoverflow.com/questions/677411

Вопрос

Я нашел это в каком-то производственном коде входа, который недавно просматривал...

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

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

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

Это было полезно?

Решение

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

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

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

Другие советы

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

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

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

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

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

И если трассировка записывается в текстовый файл, это будет стоить дороже, чем запись в консоль, ИМХО

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top