Веб-приложения 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 изменение поведения?