Профилирование в реальном времени = 45 секунд, но время потока = 0,387 секунд, что может вызвать это расхождение?

Question

Итак, наш хостинг-провайдер недавно переместил наш тестовый сервер из одной среды в другую, виртуализированную среду. После перемещения некоторые вещи в тестовой среде стали очень медленными.

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

Последняя интересная находка была обнаружена, когда я установил dotTrace на тестовом сервере. Запуск страницы, которая, как я знал, будет работать плохо, я получил следующие (высокоуровневые) результаты для потока, который выполнил работу для проблемной страницы:

Real/wall time: 45538 ms
Thread time:    375 ms

Насколько я знаю, это означает, что Поток тратит ужасно долгое время, не будучи исполненным. Моя собственная теория о том, что виртуальная среда отдает приоритет работе других серверов над моим сервером. Может ли это быть причиной? Что ты думаешь?

Примечание: если вам нужны более подробные данные, такие как фактические следы, у меня нет проблем с их выдачей, если вы спросите. Редактировать: Подробнее! Самые дорогие звонки в трассировке:

1 вызов KeyInfoX509Data.ctor (X509Certificate, X509IncludeOption): 30014 мс
1 звонок в SignedXml.ComputeSignature: 15045 мс

Детали трассировки

Answer 1

Для меня это несоответствие кричит о проблемах с IO. Скорее всего, диск или сеть, хотя процессор меня тоже не удивит.

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

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

В зависимости от VM Server и аппаратного обеспечения, это может быть настройка для настройки или не может быть. Если это не так, вы ничего не можете с этим поделать.

В любом случае, я согласен с вашей теорией: скорее всего, это не проблема вашего приложения, а скорее проблема вашего провайдера. Если у вас есть какое-либо влияние на интернет-провайдера, я бы поблагодарил его за разрешение и / или расследование смены провайдера. Вероятность того, что его взломают, может существенно превзойти то, что они просто выделят вам какое-то оборудование или пойдут к поставщику, который может предоставить вам необходимую услугу.

Answer 2

Так что это оказалось проблемой безопасности / сети / DNS. Одна из регистраций DNS на сервере была неправильной. Это привело к тому, что при попытке поиска на сервере AD был возвращен неправильный IP-адрес. Это тогда привело к таймаутам при запросе информации AD, что затем снова привело к некоторым другим проблемам Все эти проблемы проявили себя как долгая пауза при запросе определенных страниц.