Мы хотим развернуть веб-сайт на II6.0 / 7.0 только для использования в интрасети. Веб-сайт имеет типичную трехуровневую архитектуру. Средний уровень развертывается как сервер приложений на том же компьютере, что и IIS. Код asp.net, запущенный в рабочем процессе, обращается к серверу приложений, который, в свою очередь, подключается к базе данных для получения данных.
Мы проводим нагрузочное тестирование с помощью Load Runner и заметили несколько вещей. Даже для 20 одновременных пользовательских тестов IIS выдает ошибки 401, 500 и тайм-аут очень случайным образом. Проблема очень случайная. Иногда тестирование для большего количества пользователей проходит без ошибок, но не удается для нескольких пользователей. Поведение IIS непредсказуемо.
1) Двухъядерный четырехъядерный процессор 2) 8 ГБ ОЗУ
Я склонен винить код asp.net. IIS должен обслуживать 250 пользователей, не беспокоясь.
В любом случае, 1) включите пользовательские ошибки, чтобы найти точную точку в приложении, где оно не работает. 2) подключите отладчик и посмотрите, где у вас есть таймауты или петли, которые не возвращаются.
Я бы подошел к этому как к простому устранению ошибки тайм-аута, а не к настройке проблем с конфигурацией.
Тот факт, что непредсказуемость, также не указывает на IIS .. это, вероятно, означает, что ошибка зависит от некоторого общего ресурса или некоторых недетерминированных путей кода.
Если ваше приложение борется с 20 одновременными пользователями и не делает что-то очень интенсивное, например, вычисление чисел промышленного уровня, я был бы склонен предположить, что виноват скорее код, чем IIS.
Мое первое предложение - проверить кодовую базу на наличие плохого дизайна / логики, оптимизировать базы данных и процедуры доступа к данным и посмотреть, имеет ли это какой-либо эффект. Вы можете попробовать использовать Resharper или подобное, чтобы помочь вам в этом.
Два слова: кеширование сервера.
Проанализируйте свое приложение и посмотрите, что можно кэшировать на каком уровне, начиная с кэширования вывода страницы Asp.Net и погружаясь в слои, добавляя кеширование на каждом уровне по мере необходимости. Найдите свои узкие места и спросите себя, как часто нужно вызывать этот процесс. Эти данные уникальны для каждого пользователя? Если нет, то кешируйте его один раз и используйте кешированное значение для последующих запросов. Данные меняются только в определенное время? Если это так, загрузите его один раз и установите срок действия кеша в это время. Я могу заверить вас, что одно это значительно улучшит ваши способности.
250 одновременных пользователей приложения, которое динамически генерирует некэшированное содержимое страницы в одном блоке, - это довольно сложная задача просто из-за ограничений самого оборудования. Каналы такие большие, и без кеширования вы быстро их заполните.
Взгляните на блог MSDN: Максимальное количество одновременных подключений к IIS6
Используйте профилировщик ANTS, чтобы найти самые медленные строки в вашем коде. Кроме того, увеличьте количество разрешенных потоков, я думаю, в файле web.config. Возможно, также увеличьте время ожидания и удалите функции (такие как getdate) и особенно функции с табличным значением из вашего кода SQL. Если вам абсолютно необходима функция в ваших представлениях, например, используйте escape-последовательности ODBC, такие как {fn curdate ()}, потому что функции ODBC являются каноническими функциями (индексируемыми), в то время как обычные функции сервера SQL недетерминированы (не индексируются).
Если вы получаете ответ 500 и тайм-аут, это означает, что веб-сервер обрабатывает запрос нормально, но время ожидания чего-то, что необходимо для выполнения запроса, истекло - вероятно, запрос, который веб-сервер отправил на сервер приложений. Если проблема возникла на веб-сервере, вы с большей вероятностью получите сбой подключения или ошибку тайм-аута сети (т. Е. Отсутствие ответа HTTP вообще), а не ответ 500. Я бы начал с просмотра показателей с серверов приложений и баз данных. Если обычные показатели выглядят хорошо, обратите внимание на поведение блокировки. Администратор баз данных должен быстро обнаружить это в базе данных, но в коде сервера приложений (я полагаю, пользовательский код?) Вам нужно будет копнуть глубже.
Я с остальными: вероятно, что-то не так с вашим приложением. Однако вы не сказали, хорошо ли работает это приложение на другом оборудовании (есть ли компьютер разработчика, на котором оно установлено, на котором вы можете запустить Load Runner?) Или нет.
При этом, если вы считаете, что оборудование и / или конфигурация сервера являются подозрительными, вы можете установить Microsoft .NET Pet Shop 4.0 (для приложений .NET 2.0) или, возможно, DotNetNuke, систему управления контентом .NET (CMS) с открытым исходным кодом на том же оборудовании и посмотрите, как они сочетаются с Load Runner. Если они оба не пройдут тесты, возможно, ваше оборудование является подозрительным (и я бы поставил его на другой компьютер для тестирования) или ваша конфигурация / параметры Load Runner неверны, и вы должны искать там.