Соединение SQL 2005 с использованием классического ADO из Windows 2008 дает странную производительность - PullRequest
1 голос
/ 05 января 2011

ОБНОВЛЕНИЕ: Пожалуйста, смотрите обновления ниже, так как я добавляю больше информации внизу, когда сталкиваюсь с этим.

Я работаю над настройкой нового веб-сервера, работающего под управлением Windows Server 2008, с подключением к другому Windows 2003 Server с помощью SQL Server 2005. Я сталкиваюсь с некоторыми странными результатами при попытке выполнить запросы с сервера на SQL Server 2005 сервер. По сути, любой другой запрос имеет фиксированные 625 миллисекундные издержки, если результаты возвращаются, но не накладные, когда он не является запросом:

Я позволю своему примеру кода VB-сценария говорить:

set cn = CreateObject("ADODB.Connection")
cn.Open "Provider=SQLNCLI;Server=thesqlserver;Integrated Security=SSPI;initial catalog=thedatabase"

t = Timer

for i = 1 to 20
    set rs = cn.Execute("select getdate()") //Note getting recordset here
    s = s & (timer - t) & VbNewLine
    t = Timer
next

for i = 1 to 20
    cn.Execute("select getdate()") //Note no recordset returned here
    s = s & (timer - t) & VbNewLine
    t = Timer
next

set fso = CreateObject("Scripting.FileSystemObject")
set file = fso.OpenTextFile("c:\results.txt", 2, True)

file.WriteLine(s)
file.Close

Вот фактические результаты:

First Set - Returning recordset
0
0.625
0
0.6640625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.625
0
0.6171875
Second Set - Non-query execution
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0.015625
0
0
0
0
0

Я сбит с толку. Любая помощь будет принята с благодарностью.

UPDATE:

В ответ на ответ Кевина я попытался запустить тот же сценарий непосредственно с сервера SQL. Результатом было ноль накладных расходов полностью вниз. Соединение между двумя серверами представляет собой перекрестный сетевой кабель, соединенный со вторыми сетевыми картами каждого сервера.

UPDATE:

Новая информация. Я попытался изменить имя сервера в аргументе «Server =», и при использовании внутреннего IP (перекрестного кабеля) IP-адрес увеличивался с 625 миллисекунд на каждый четный запрос до 4550 миллисекунд на любой четный запрос (с нечетными запросами по-прежнему на нуле). Затем, изменив его на общедоступный IP-адрес, затраты полностью исчезли! Я должен что-то неправильно настроить на внутренней сетевой карте.

UPDATE:

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

Ответы [ 2 ]

0 голосов
/ 23 июня 2011

На данный момент единственное решение, которое я могу найти, это ссылаться на внешний IP-адрес по сравнению с внутренним IP-адресом.Я не уверен, оказывает ли это какое-либо влияние на производительность (т. Е. Является ли маршрут, по которому пакеты занимают больше времени), но по крайней мере он работает.

0 голосов
/ 05 января 2011

Существуют дополнительные затраты при настройке объекта набора записей, но кажется, что 625 мс - это немного круто, возможно, придется уничтожить существующий набор записей и вставить новый.

В любом случае, если я выполняю запрос действия и мне не нужен набор записей, я всегда использую дополнительную опцию adExecuteNoRecords, чтобы никакой набор записей не был установлен и запрос выполнялся быстрее.

...