2011-01-05 1 views
1

ОБНОВЛЕНИЕ: см. Ниже приведенные ниже обновления, поскольку я добавляю больше информации в нижнюю часть, когда я сталкиваюсь с ней.Соединение SQL 2005 с использованием классического ADO из Windows 2008 дает нечетную производительность

Я работаю над созданием нового веб-сервера под управлением Windows Server 2008, подключающегося к другому серверу Windows 2003 с 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. Результат был нулевым наклонным вниз. Соединение между двумя серверами представляет собой кроссоверный сетевой кабель, подключенный ко второму сетевому адаптеру каждого сервера.

ОБНОВЛЕНИЕ:

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

UPDATE:

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

+0

Можете ли вы попробовать создать новый набор записей во втором тесте, но не назначать ему результаты? например add rs = Server.CreateObject ("ADODB.Recordset") перед cn.Execute(). Я давно не пользовался старой школьной аспидией, поэтому простите меня, если это не так. В любом случае, это скажет вам, является ли сервер sql или накладные расходы для создания набора записей. Кроме того, таймер не особенно точен в этом типе цикла, попробуйте просто сравнить время в начале и конце каждого цикла. –

+0

Спасибо за предложение, jamietre. Я попробовал это и получил те же результаты, что и выше - добавление CreateObject («ADODB.Re: используя таймер, я тоже подумал об этом. Но я думаю, что точность - это больше проблема, когда вы приближаетесь к миллисекунде. До того, как я использовал таймер и log, я использовал поле для сообщений между каждой итерацией, и я видел те же результаты: каждый нечетный запрос сразу появлялся в окне сообщения, каждый четный запрос приостанавливал 1/2 секунды или больше, чтобы всплывать окно. –

ответ

0

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

0

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

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

+1

Спасибо, Кевин. если я запускаю тот же самый сценарий с SQL-сервера, я получаю нулевые накладные расходы. И странно, что это всегда точно каждый другой запрос. Это тот случай, если я разрешаю ему работать на 100 итераций - он чередуется между 0 и 625, Я обновляю свое оригинальное сообщение с этой информацией. –

 Смежные вопросы

  • Нет связанных вопросов^_^