тайна узкого места производительности ASP.NET

Question

Классическое приложение ASP.NET - AppSrv + MS SQL DB. Оба сервера тяжелые 8 ядер, 20 ГБ оперативной памяти. При нагрузочном тестировании пропускная способность где-то достигает 400 VirtualUsers (согласно LoadRunner), при этом центральный процессор примерно на 30% использует сервер БД, в основном на холостом ходу - время отклика резко возрастает, вплоть до отсутствия ответа.

Обычные подозрения, такие как исчерпание Max Pool и ограничение conn в ASP.NET, не являются ошибкой: Max Pool установлен в 200 и используется около 80 conns; ограничение conn установлено на 0.

Я запустил с помощью профилировщика ANTS код, и он показал, что блокировка потоков не внесла существенного вклада.

Идеи очень, очень приветствуются!

Answer 1

Недавно мы настроили наше веб-приложение, используя следующее Руководство по настройке производительности IIS , которое оказалось очень успешным.

Были изменены две специфические настройки сервера;

Использование памяти рабочего набора - Серверы под управлением Windows Server ™ 2003 по умолчанию настроены так, чтобы при выделении памяти отдавать предпочтение кэшу файловой системы над рабочим набором. Microsoft делает это, потому что Windows выигрывает от большого кеша файловой системы. Поскольку IIS работает поверх операционной системы Windows, он также выигрывает от наличия большого кэша файловой системы. Однако если ваш сервер является выделенным сервером IIS, производительность может повыситься, если вместо этого перенести приоритет на рабочий набор. Причиной этого является то, что если предпочтение отдается кешу файловой системы, код для постраничного ввода часто записывается в виртуальную память. В следующий раз, когда эта информация понадобится, что-то еще должно быть выгружено в виртуальную память, а ранее выгруженная информация должна быть считана в физическую память, прежде чем ее можно будет использовать. Это приводит к очень медленной обработке.

Пропускная способность сети - По умолчанию серверы, работающие под управлением Windows Server 2003, сконфигурированы так, чтобы отдавать предпочтение кэшу файловой системы по сравнению с рабочими наборами процессов при выделении памяти (через свойство сервера Максимизировать пропускную способность для обмена файлами ). Хотя серверы на основе IIS 6.0 выигрывают от большого кеша файловой системы, предпочтение кеша файловой системы часто приводит к записи на страницу кода IIS 6.0 на диск, что приводит к длительным задержкам обработки. Чтобы избежать этих задержек обработки, задайте свойства сервера, чтобы максимизировать пропускную способность данных для сетевых приложений.

Следующие службы не требуются на выделенном веб-сервере:

• Alerter
• ClipBook
• Браузер компьютера
• DHCP-клиент
• DHCP-сервер
• Факс
• Репликация файлов
• Инфракрасный монитор
• Общий доступ к подключению к Интернету
• Messenger
• Общий доступ к удаленному рабочему столу NetMeeting
• Сеть DDE
• Сеть DDE DSDM
• NWLink NetBIOS
• NWLink IPX / SPX
• Диспетчер очереди печати
• Вспомогательная служба TCP / IP NetBIOS
• Телефония
• Telnet
• Источник бесперебойного питания

Answer 2

Возможно, проблема в вашем machine.config файле.

Вы должны проверить следующие параметры конфигурации:

• maxconnection
• maxIoThreads
• maxWorkerThreads
• minFreeThreads
• minLocalRequestFreeThreads

Для краткого описания проверьте: Настройка IIS 6.0 для производительности

Есть некоторые различия между ASP.NET 1.1 и ASP.NET 2.0

ASP.NET 1.1

Рекомендации по некоторым практическим ценностям, которые вы можете найти в:

• Microsoft Kb, статья 821268
• Статья MSDN «Глава 6 - Повышение производительности ASP.NET - Объяснение потоков»

Значения по умолчанию являются низкими для любого практического использования и должны быть исправлены в соответствии с предложениями в связанных статьях.

ASP.NET 2.0

Параметры перемещаются в секцию processModel и параметры настраиваются автоматически. Помимо автоматической настройки, вы можете установить значения параметров вручную, поэтому вам следует проверить:

• processModel включено
• autoConfig установлено на true
  или
• параметры установлены на правильные значения

Для подробного описания проверьте: Модель ASP.Net 2.0 process

Answer 3

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

Как и другие предлагали, добавление регистрации / профилирования на стороне базы данных покажет, заблокирован ли он (или похожий).

Answer 4

Когда нет процессоров, и страницы обычно перестают отвечать на запросы, моя первая догадка - блокировка базы данных. Один поток может задержать остальные, если не снимать блокировку с таблицы, что приводит к тому, что страницы не реагируют на работу на холостом ходу вашего сервера БД.

Можете ли вы использовать средство мониторинга sql для проверки правильности использования на компьютере базы данных и проверки правильности получения данных всеми пользователями?

Еще одна вещь; какую информацию вы можете дать по использованию памяти?

Answer 5

Это может быть длинный выстрел, но вы можете попробовать запустить свой код через Patterns and Practices Checker , чтобы проверить, не найдет ли он какой-нибудь низко висящий фрукт.

Answer 6

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

Answer 7

Хост использует пул приложений?

Вы пытались увеличить число с 5 до 10 в

An Application Pool -> Performance -> 
Web Garden -> Max Number of worker processes