Низкая производительность с SecuritySafeCriticalAttribute на win server 2008

Мое приложение тратит слишком много времени на метод Wait

Окружающая обстановка:

  • .Нет 4.0
  • Платформа приложений x86
  • Консольное приложение
  • Вин сервер 2008 (x64)

Я проверил производительность с помощью dottrace

Wait отмечен SecuritySafeCriticalAttribute

Обратите внимание, на Win7 (x64) все работает нормально. Я ничего не нашел, любые предложения приветствуются.

Обработка задач

private readonly BlockingCollection<TTask> _queue = new BlockingCollection<TTask>();
private Thread _workThread;

public void ProcessTask(TTask task)
{
    _queue.Add(task);
}

private void ProcessTask()
{
    while (_isRun)
    {
        try
        {
            TTask task = _queue.Take();
            if (task.IsNull())
            {
                continue;
            }
            _log.DebugFormat("Sending task: {0}", task);
            DoProcessMessage(task);
        }
        catch (Exception ex)
        {
            _log.Error(ex);
        }
    }
}

person GSerjo    schedule 17.12.2012    source источник


Ответы (2)


Я не думаю, что атрибут безопасности влияет на скорость. Длительное время ожидания здесь занимает много времени, вероятно, потому, что вы получаете доступ к защищенному объекту (некоторой коллекции) из нескольких потоков одновременно и держите объект заблокированным в течение длительного времени (например, пока ваш код обрабатывает каждый элемент в коллекции). Это неправильный способ использования коллекции и, безусловно, узкое место в вашем коде.

person Eugene Mayevski 'Callback    schedule 17.12.2012
comment
Я использую BlockingCollection, поэтому lock у меня нет. Обратите внимание: проблема отсутствует на win7 (x64) - person GSerjo; 17.12.2012
comment
Комментарии к методу Take() предполагают, что вам может понадобиться добавить вызов CompleteAdding() после Add(): msdn.microsoft.com/en-us/library/dd287085%28v=vs.100%29.aspx - person Eugene Mayevski 'Callback; 17.12.2012

Решено

Похоже, dotrace показывает погоду. Я проверил производительность с помощью Профилировщика производительности ANTS и устранил проблему. Проблема была в запросе sql через NHibernate

person GSerjo    schedule 17.12.2012