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

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

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

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

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

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

Примечание. Если вам нужны дополнительные сведения, например фактические трассировки, я без проблем раздам ​​их, если вы попросите.

Изменить: подробнее! Самые дорогие вызовы в трассировке:

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

.net asp.net profiling dottrace
person JohannesH    schedule 21.12.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Для меня это несоответствие кричит о проблемах с ожиданием ввода-вывода. Либо диск, либо сеть, скорее всего, хотя CPU меня тоже не удивит.

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

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

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

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

person James    schedule 21.12.2009
comment
+1, согласен с Джеймсом. Вызовы двух методов, скорее всего, привязаны к вычислительным ресурсам, поэтому рекомендуется, чтобы ваш интернет-провайдер проверял загрузку ЦП сервера. - person Jeremy McGee; 21.12.2009
comment
Спасибо за Ваш ответ. Если окажется, что это процессор или ввод-вывод, подождите, я соглашусь. А пока +1. ;) IO и CPU всегда были моими главными подозреваемыми, но это только догадка, так как я не могу профилировать фактический виртуальный сервер. Я надеюсь, что хостинг-провайдер где-нибудь обнаружит настраиваемый параметр. - person JohannesH; 22.12.2009
comment
Оказалось, что это не имеет никакого отношения ни к процессору, ни к дискам. Проблема была вызвана неправильной регистрацией DNS-сервера на рассматриваемом сервере. Я ответил на вопрос ниже. Но для других, кто может прочитать это, вероятно, более вероятно, что причина связана с загрузкой процессора или диска. - person JohannesH; 23.12.2009

arrow_upward
0
arrow_downward

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

person JohannesH    schedule 23.12.2009