Как трассировка system.diagnostics влияет на производительность .net? - PullRequest
Новая
       17

Как трассировка system.diagnostics влияет на производительность .net?

2 голосов
/ 14 января 2010

Когда я включаю трассировку, например: 

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel" switchValue="Warning">
            <listeners>
                <add name="_listener0" />
            </listeners>
        </source>
    </sources>
    <sharedListeners>
        <add name="_listener0" type="System.Diagnostics.XmlWriterTraceListener"
         initializeData="logs\ServiceModel.svclog" traceOutputOptions="DateTime, ProcessId, ThreadId, Callstack" />
    </sharedListeners>
    <trace autoflush="true" />
</system.diagnostics>

Насколько сильно это влияет на производительность приложения?

Ответы [ 4 ]

2 голосов
/ 14 января 2010

Как и в большинстве вопросов, ответ «зависит». Вы включаете Tracing для компонентов WCF или используете собственные вызовы трассировки? Подключен ли прослушиватель трассировки (например, запись в файл? Или инструмент DebugView открыт для просмотра консоли отладки системы)? Ваш код интенсивно использует трассировку в узких циклах или более умеренную трассировку только для нерекурсивных функций и т. П.?

Вы можете попробовать и посмотреть, но для большинства приложений вы заметите.

0 голосов
/ 25 октября 2010

Обязательно <очистите /> прослушиватель по умолчанию, если вы беспокоитесь о производительности.

Мысли о трассировке System.Diagnostics по сравнению с Common.Logging

0 голосов
/ 24 февраля 2010

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

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

   UI Client (local pc)
      -> WCF service 1 (hosted locally)
         -> WCF service 2 (hosted locally)
            -> webservice hosted by business partner (offsite)

Клиент пользовательского интерфейса, а также службы WCF 1 и WCF 2 отслеживаются с использованием System.Diagnostics.XmlWriterTraceListener.

Установлено на "ВСЕ", процесс в среднем составляет 530 мс .
При значении «ВЫКЛ» процесс в среднем составляет 400 мс .

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

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

0 голосов
/ 14 января 2010
  1. Решите, какие издержки производительности для трассировки приемлемы для вас.
  2. Измерьте фактические издержки производительности.
  3. Если 2 <= 1, то смайлики со всех сторон. </li>
  4. Если 2> 1, измените свою трассировку (например, сделайте ее менее многословной, измените прослушиватель трассировки) и вернитесь к 1.
...