Веб-приложения ASP.NET 2.0-4.0 испытывают чрезвычайно медленный первоначальный запуск.

(Извините, если это очень длинный вопрос, он сказал, что он определен)

В компании, в которой я работаю, есть несколько сайтов, которые работают в течение некоторого времени без проблем. Приложения представляют собой сочетание ASP.NET 2.0, 3.5 и 4.0, все из которых используют ADO.NET для подключения к экземпляру SQL Server Standard (на том же веб-сервере), который размещается в IIS7.

Проблема началась, когда мы перешли на обновленный веб-сервер. Мы приложили все усилия, чтобы настроить сервер, db-экземпляр и IIS с такими же настройками (за исключением другого имени машины и того факта, что мы обновили с SQLExpress до стандарта), и насколько мы могли бы сказать, мы сделали, Оба сервера работают под управлением Windows Server 2008 R2 (все текущие обновления применяются) и получили установку по умолчанию.

Проблема очень очевидна при запуске одного из этих приложений. Когда вы попадаете на страницу входа в систему нашего приложения, сама страница загружается очень быстро. Это справедливо даже при загрузке страницы с новой машины, которая не может быть кэширована на странице, при этом кеширование IIS отключено. Проблема действительно видна, когда вы вводите свою регистрационную информацию и нажимаете кнопку входа в систему. Из-за (не большого) дизайна наших баз данных процесс входа в систему должен иметь доступ к нескольким базам данных, теоретически до 150 отдельных БД, но на практике обычно 2. Проблема возникает даже при открытии только двух баз данных (минимум). Не отличный дизайн, но мы должны жить с ним на данный момент.

При попытке изначально открыть соединение с базой данных весь процесс останавливается примерно на 20 секунд каждый раз, независимо от того, подключаетесь ли вы к 2 dbs или 40. Я запустил .NET-профайлер (jetbrains dottrace) против процесс, и единственная информация, которую я мог извлечь, заключалась в том, что один или все вызовы sqlconnection.open() составляли 90% времени. Это происходит только при первом использовании приложения, но проблема усугубляется тем фактом, что IIS, по-видимому, не учитывает настройки утилизации, которые мы установили для него, и перерабатывает приложение через несколько минут бездействия, в результате чего проблема возникает снова,

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

В ходе исследования проблемы я попробовал пару решений

  • Думая, что это может быть проблема разрешения имен, я пробовал модифицировать как файл hosts на веб-сервере, так и дать connectionstrings IP-адрес вместо имени сервера для решения без разницы. Я слышал о протоколе LLMNR, вызывающем такие проблемы, но я думаю, что попытка подключиться по IP или разрешить с файлом hosts должна была устранить эту возможность, я признаю, что никогда не пытался фактически отключить LLMNR.

  • Я увеличил тайм-ауты простоя, интервалы повторного использования и т.д. в IIS, но это, похоже, даже не соблюдается, а тем более решает проблему. Это заставляет меня думать, что есть настройка, которая отменяет настройки приложения IIS на машине.

  • несколько других исправлений кода, ни одна из которых не имела никакого значения. Устанавливается ли параметр SqlServer, вызывающий проблему?

  • прочее, что я забыл.

Любые идеи, опыт или whatevers были бы очень благодарны за помощь в решении этой проблемы!

Ответ 1

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

Именованные каналы

Data Source=np:computer\instance

Общая память

Data Source=lpc:computer\instance

Лично я предпочитаю общую память. Помните, что вам нужно включить эти протоколы и избежать ошибок конфигурации. Я предлагаю вам отключить все, что вы не используете.

см. http://msdn.microsoft.com/en-us/library/ms187892.aspx

IIS Reset

В IIS7 существует два способа настройки тайм-аута бездействия. Оба начинаются с нажатия на раздел "Пулы приложений" и щелкните правой кнопкой мыши соответствующий домен приложения. Если вы нажмете опцию "Переработка...", появится одна настройка. В разделе "Расширенные настройки..." в разделе "Модель процесса" вы найдете "Тайм-аут простоя (минуты)", который установлен на ноль, отключает тайм-аут процесса. Этот более поздний вариант - это тот, который работает для нас.

Если бы я был вами, я бы разрешил эту проблему сначала, так как перезагрузка процесса appdomain и/или рабочего процесса всегда болезненна, даже если у вас нет отставания в 20 секунд.

Ответ 2

Некоторые идеи:

  • с веб-сервера, вы можете выполнить ping-сервер db и получить "обычный" ответ, или вы видите подобную задержку?
  • если вы видите задержку, запустите tracert, чтобы увидеть, можете ли вы пригвоздить место, где происходит медлительность.
  • попробуйте использовать такой инструмент, как QueryExpress (http://www.albahari.com/queryexpress.aspx), который не требует установки для запуска. Вы можете загрузить этот EXE и запустить его со своего веб-сервера. Посмотрите, можете ли вы подключиться к своему db, используя это и запуская запросы обычным способом.
  • Попробуйте что-то вроде TcpView от SysInternals (http://technet.microsoft.com/en-us/sysinternals/bb897437), чтобы просмотреть открытые подключения и посмотреть, какие действия происходят на вашем сервере и сколько данных отправляется на ваш сервер db и получает его.

Просто начальные мысли о том, где я начну смотреть, основываясь на вашем описании проблемы. Надеюсь, это поможет. Удачи с вещами!

Ответ 3

Когда IIS не соблюдает настройки утилизации: перезапустил ли IIS/reboot изменение поведения?