Как игнорировать длительное ожидание сигнала при анализе конфликтов с использованием профилировщика Visual Studio? - PullRequest
2 голосов
/ 28 марта 2020

Я попытался профилировать приложение, чтобы увидеть потенциальные проблемы с конфликтами потоков, используя профилировщик Visual Studio, но проблема в том, что профилировщик считает, что ожидание сигналов является худшим нарушителем (потому что поток-потребитель ждет сигнала большую часть времени) в то время как на самом деле было бы интереснее увидеть раздоры на стороне продюсеров.

Например, я использую асинхронное приложение для журнала 4net, чтобы уменьшить влияние ведения журнала на реальных работников, и это в основном оболочка BlockingCollection<T>:

readonly BlockingCollection<LoggingEventContext> _queue;

protected override void Append(LoggingEvent e)
{
    // instead of appending, push to the queue
    _queue.Add(new LoggingEventContext(e, HttpContext), _loggingCancelationToken);
}

void StartForwarding()
{
    _queue = new BlockingCollection<LoggingEventContext>(BufferSize);

    _loggingCancelationTokenSource = new CancellationTokenSource();
    _loggingCancelationToken = _loggingCancelationTokenSource.Token;
    _loggingTask = new Task(SubscriberLoop, _loggingCancelationToken);
    _loggingTask.Start();
}

Долгосрочное задание - это когда события перенаправляются фактическим добавителям:

void SubscriberLoop()
{
    try
    {
        // this is the blocking call which is reported as the source of contention
        foreach (var entry in _queue.GetConsumingEnumerable(_loggingCancelationToken))
        {
            HttpContext = entry.HttpContext;
            ForwardLoggingEvent(entry.LoggingEvent, ThisType);
        }
    }
    catch (OperationCanceledException ex)
    {
        ...
    }
    catch (ThreadAbortException ex)
    {
        ...
    }
}

Мой вопрос: я что-то не так делаю? Как правильно использовать профилировщик для определения фактических горячих точек?

...