Веб-интерфейс и база данных моего сайта разделены на два сервера, соединенных локальной сетью на скорости 1000 Мбит/с.
Я обнаружил, что почти каждый запрос имеет время отклика более 800 мс. Я могу быть уверен, что все мои запросы в порядке, потому что когда я развертываю их на одном сервере, проблема не возникает.
веб-сайт/asp.net 2.0 база данных/sql сервер 2000
решение1
Если ваш DNS вызывает задержку в 800 мс для (как и должно быть) кэшированного IP-адреса, то с настройками вашей сети что-то серьезно не так. IMHO. Вы можете проверить, является ли это проблемой, с помощью ping.
Используйте traceroute, чтобы убедиться, что пакеты используют эффективный маршрут между двумя компьютерами. Это легко сделать, поэтому стоит попробовать, прежде чем возиться с другими вещами. Если в маршруте много переходов, может быть, больше двух или трех, найдите сетевого специалиста и спросите его, почему так.
При попытке устранения неполадок сети SQL лучше всего использовать очень простой запрос, например "SELECT GETDATE()", и использовать простой инструмент запросов, например SQLCMD.EXE. Простой запрос означает, что серверу не придется тратить много времени на разбор запроса, не будет никаких существенных блокировок или блокировок, и запрос не вернет миллионы строк данных по сети. Простой инструмент запросов означает, что вам не нужно беспокоиться о том, что может или не может делать IIS. Если на сервере IIS не установлен SQLCMD.EXE, OSQL.EXE или аналогичный инструмент, возможно, стоит написать небольшой скрипт psh или vbs для проверки подключения к SQL Server. Если у вас нет такого доступа к серверу IIS, вы, вероятно, могли бы написать специальную страницу ASP, которая просто запускала этот простой запрос и возвращала результат и время, которое потребовалось для его выполнения.
Если мне придется угадывать проблему, то она будет вот в чем-> Особенно со старым оборудованием и драйверами, не полагайтесь на настройки "автосогласования" на сетевых картах. Установите обе карты на одинаковые настройки вручную.
Я знаю, что это муторно, но я лично видел, как это решило около десятка подобных проблем, когда сетевые специалисты были в тупике. (В конце концов, это серверы, и они не будут подключены к множеству разных коммутаторов и им не придется пересогласовывать скорость соединения или настройки дуплекса.)
Эту проблему можно также увидеть, наблюдая за скоростью передачи данных на сетевых картах, измеряемой в МБ/сек, с помощью Performance Monitor. После того, как вы установили базовый уровень, измените настройки на сетевых картах и снова наблюдайте.
Обычно можно обойтись изменением этих настроек «на лету», но я бы не стал пробовать это во время пиковой нагрузки, когда я впервые игрался с этими настройками. Лучше провести испытание в тестовой среде, если она у вас есть. Если у вас есть окно обслуживания, это будет лучше всего. Если на сервере только 1 сетевой адаптер, будьте осторожны и не настройте сетевой адаптер так, чтобы он не мог общаться с коммутатором, иначе вам, возможно, придется попросить кого-то физически войти в консоль, и это будет неприятно для всех.
решение2
Возможных причин может быть много. Например, проблема может быть в одном из драйверов сетевого адаптера.
Вам придется проверить, является ли SQL-соединение узким местом или это общая проблема сети. Попробуйте выполнить команду "select getdate()" с веб-сервера, чтобы увидеть, затронуты ли все запросы.
Пинги к серверу базы данных тоже медленные? Также попробуйте использовать IP-адрес вместо имени сервера - возможно, это проблема разрешения DNS.