Я попытался профилировать приложение, чтобы увидеть потенциальные проблемы с конфликтами потоков, используя профилировщик 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)
{
...
}
}
Мой вопрос: я что-то не так делаю? Как правильно использовать профилировщик для определения фактических горячих точек?