PHP SQLSRV имеет промежуточную задержку на sqlsrv_fetch_array/sqlsrv_fetch

Question

, мы переключили наше соединение с DB из ADODB на SQLSRV, и у меня, похоже, возникли проблемы с этим, вызвав промежуточные задержки с использованием sqlsrv_fetch_array.

Я делаю запрос в своей базе данных, который возвращает около 426 строк с 5 полями.

код выглядит следующим образом (для скорости тестовых целей я действительно удален всего остального она делает):

$conn = sqlsrv_connect($host, array("UID"=>$userName,"PWD"=>$password,"Database"=>$dbName,"QuotedId"=>false, "CharacterSet" =>"UTF-8"); 

$rsText=sqlsrv_query($conn,$sqlStr,array(), 
       array(
        "Scrollable"=>SQLSRV_CURSOR_STATIC 
       )); 

$row = array(1); 
while(count($row) != 0){ 
    $row=sqlsrv_fetch_array($rsText,SQLSRV_FETCH_BOTH, SQLSRV_SCROLL_NEXT); 
} 

Запуск этого с ADODB берет меня около 50мса. Запуск его с помощью sqlsrv займет от 500 до 1000 мс. Исходный запрос (sqlsrv_query) на самом деле быстрее с sqlsrv, чем ADODB, но есть случайные задержки времени с sqlsrv_fetch_array (я действительно тестировал с sqlsrv_fetch, а также получал их). Я запрограммировал в ms каждый звонок, и, хотя обычно это 0-1мс за звонок, иногда это будет до 15 мс. Почему я говорю, что случайным является то, что если я повторно запускаю код несколько раз, задержки не будут происходить в одном и том же месте и будут меняться по количеству, поэтому это происходит не потому, что определенная строка большая (ни одна из них ни одна из них) ,

Есть ли у кого-нибудь идеи, на что я мог смотреть, что это может быть сделано, будь то параметр или конфигурация где-нибудь? Я не думаю, что это связано с сервером/сетью, поскольку ADODB этого никогда не делает. Мы используем PHP 5.6 и php_sqlsrv_56_ts.dll/php_pdo_sqlsrv_56_ts.dll и SQL Server 2008.

Спасибо!

Answer 1

Как было предложено alalp в комментариях, я попытался изменить тип прокрутки и устранил проблему.

Я сделал несколько быстрых тест, и вот что я получил:

SQLSRV_CURSOR_STATIC, SQLSRV_CURSOR_KEYSET и SQLSRV_CURSOR_DYNAMIC: тяжелая скорость проблема. Как указано в исходном посте, зацикливание даже на умеренном количестве записей (несколько 100 секунд) заняло бы секунду.

SQLSRV_CURSOR_FORWARD: нет скорости. Взял около 50 мс, чтобы прокрутить записи из моего примера, что было таким же, как ADODB. Вы теряете способность делать MoveFirst/MovePrev, но я думаю, что это легко разрешить, сохраняя результаты в массиве на вашем первом проходе, если это необходимо, или в зависимости от запроса, может быть, просто повторить его в редких случаях, когда это обязательный.

SQLSRV_CURSOR_CLIENT_BUFFERED: пылающий быстро (в моем 0 мс, например, что имеет смысл, потому что от моего понимания, что это в основном так же, как хранить всю вещь в массиве). Однако у нас были проблемы с памятью в некоторых более крупных наборах данных.

В нашем проекте мы закончили использование SQLSRV_CURSOR_CLIENT_BUFFERED для общедоступного веб-сайта, потому что на одной странице не было извлечено ни одного основного набора данных, а SQLSRV_CURSOR_FORWARD для бэкэнд-сервера, где вы можете вывести 1000 строк данных.