У нас есть бизнес-приложение на ASP.NET + SQL Server 2008.
Вначале SQL Server и IIS находились на одной машине. Сейчас мы купили другую машину. Текущая конфигурация - это машина IIS плюс машина SQL Server, и они подключены через LAN-соединение 1 ГБ.
В этой конфигурации наше веб-приложение работает медленнее, чем раньше. Максимальная пропускная способность составляет 1-2% сети, около 15 Мбит / с.
Когда мы используем другие потоки к тому же SQL Server с того же компьютера IIS, использование сети увеличивается. Так что с SQL Server проблем нет.
Как мы можем увеличить пропускную способность для этого SQL-соединения?
Технические характеристики:
Используя Profiler, изучите запросы, выполняемые в экземпляре SQL.
Если приложение плохо закодировано, вы можете оказаться в сценарии «смерть на 1000 сокращений», когда есть сотни или тысячи небольших, возможно, несущественных запросов, возвращающих отдельные строки, а не набор, или JOINed результат. Каждый раз, когда приложению требуются данные для одного из этих наборов запросов, разделение уровней приводит к огромной дополнительной задержке при подключении к сети. Это довольно нелогично, если вы раньше не видели такой ситуации.
Запуск Profiler на сервере с относительно большим объемом запросов может быть трудным, но если это такой большой объем, вы можете включить его несколько раз, по 1-2 минуты за раз, и получить хороший образец. Что бы ты ни делал, не запустите Profiler через сетевое соединение. Либо запустите Profiler в окне SQL Server через RDP, либо настройте трассировку для запуска на самом экземпляре (предпочтительно).
Я полагаю ты мог используйте оборудование, чтобы уменьшить задержку в сети. ИМО, это действительно не масштабируется, но если вы находитесь в затруднительном положении с огромным приложением, которое необходимо исправить, это вариант, по крайней мере, временно.
Это сервера хорошего качества с приличными сетевыми картами? дешевые сетевые карты (например, дешевые RAID-карты) - ложная экономия. А все драйвера самые свежие? Вы должны начать с одного конца и постепенно проверять, что все имеет чистую конфигурацию. Затем приступайте к устранению неполадок.
И достаточно ли памяти вы выделили для своих процессов?
Всегда ищите «разные» вещи. Мой последний странный сервер - это высокопроизводительный сервер, который работал медленно. Много процессора, памяти, нет активности на диске и т. Д. Диспетчер задач показал 120 000 дескрипторов ?! Драйвер принтера пропускал ручку каждые 2 секунды.
Когда и веб-сервер, и SQL Server находятся на одном компьютере, по умолчанию shared memory используется для протокола. Если вы переместите SQL Server в другой ящик, связь должна идти через TCP/IP.
Обычно при использовании общей памяти клиентское приложение может читать tabular data streams (TDS) прямо из памяти SQL Server. При использовании протокола TCP / IP TDS должен быть преобразован в TCP / IP на сервере, отправлен клиенту и преобразован обратно в TDS, что требует времени.
Кажется, я не могу найти хорошую ссылку на последние версии, но прочтите этот, с тех пор он не сильно изменился.
Если ваше приложение работает на том же компьютере, что и ваш SQL Server, рассмотрите возможность использования сетевой библиотеки с общей памятью, если вы еще этого не сделали. Общая память Подключения на основе сетевой библиотеки часто значительно быстрее, чем другие типы подключений. Однако не забывайте о том, что я сказал ранее: всегда тщательно тестируйте решение и сравнивайте его с жизнеспособными альтернативами, прежде чем предполагать, что оно по своей сути лучше или быстрее. Доказательство в пудинге.
и это сообщение в блоге дает также краткий обзор. Более техническое объяснение можно найти на простом разговоре
Начните с загрузки счетчиков sql монитора производительности в sql box и посмотрите.
приложение .net? есть вероятность, что он написан плохо, повсюду специальные запросы.
Вы используете 100% сохраненные процессы? Если нет, то должна быть веская причина.
Наличие SQL-сервера в одном и том же блоке, вероятно, маскировало некоторые из неудачных дизайнерских решений, ранее сделанных в приложении. Теперь они у всех на виду.
SQL-запросы могут быть невероятно быстрыми на модеме 56k, если возвращается только набор результатов. Но не в том случае, если вы делаете такие вещи, как использование курсоров на стороне клиента, когда вам нужно перетащить все обратно по сети.