производительность — PHP SQLSRV имеет прерывистую задержку на sqlsrv_fetch_array / sqlsrv_fetch

мы переключили наше соединение с БД с 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, а также получал их). Я рассчитывал в мсек каждый звонок на него, и хотя обычно он составляет 0-1 мс на звонок, иногда он составляет до 15 мс. Почему я говорю, что это случайно, потому что, если я перезапущу код несколько раз, задержки не будут происходить в одном и том же месте и будут различаться по номерам, поэтому это не потому, что конкретная строка велика (что ни один из них не является в любом случае) ,

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

Спасибо!

2

Решение

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

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

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

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

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

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

0

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector