Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 36   вперед  Ctrl
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
dimitr,

dimitr
Во-первых, для начала можно было почитать тут, а уже потом постить.

Читал, еще в далеком 2012 году, правда не известно чем все закончилось, и в какую версию это вошло.
Там все супер, и даже говорится про те же проблемы и подходы в их решении. Однако, там все зависит от глобальной настройки на клиенте (TcpRemoteBufferSize).
Я же предлагал дать возможность гибкого задания этого значения (или аналогичного, но пересчитанного в количествах записей, а не байт) самим прикладным софтом для того или иного запроса. Мне кажется очевидным, что для некоторых запросов есть необходимость prefech-ить большее количество записей, для остальных это будет даже вредно. Эту информацию знает только сам прикладной софт, а никак не администратор.

Все остальное остается так же как описано в статье - запрос новых данных при срабатывании порога конвейерной обработки, определение медленных и быстрых сетей.

Из статьи
Как только клиентская библиотека обработала некоторую часть текущего пакета, она запрашивает у сервера следующий пакет и продолжает обработку оставшихся записей.

Клиентская библиотека делает это асинхронно, включая прием данных?

dimitr
Во-вторых, если клиентская либа закешировала N записей, в чем архи-полезность возвращать их по индексу, а не последовательно?

Вы про мое описание в тикете о подробностях реализации в Postgres?
Да, кто их знает зачем они так сделали. Описание приложено для демонстрации подходов в решении этой задачи.
Как бы там не было, "fetch FORWARD count" и OCI_ATTR_PREFETCH_ROWS свое дело делают.
27 фев 19, 19:22    [21821041]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47399

rashid.abzalov
Как бы там не было, "fetch FORWARD count" и OCI_ATTR_PREFETCH_ROWS свое дело делают.

Фигнёй эти костыли маются.

И да, клиентская библиотека посылает запрос на новую порцию данных ещё до того, как
полностью отдаст приложению старую.

Posted via ActualForum NNTP Server 1.5

27 фев 19, 19:48    [21821071]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rashid.abzalov
hvlad
Batch API

На сколько я понял, они только для insert/update, а я говорил про select.
Для select планируется вторая часть - Pipe API.
27 фев 19, 19:52    [21821078]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rashid.abzalov
Я же предлагал дать возможность гибкого задания этого значения (или аналогичного, но пересчитанного в количествах записей, а не байт) самим прикладным софтом для того или иного запроса. Мне кажется очевидным, что для некоторых запросов есть необходимость prefech-ить большее количество записей, для остальных это будет даже вредно. Эту информацию знает только сам прикладной софт, а никак не администратор.
Никто никогда не скажет чем префетч N записей лучше префетча M записей.
Максимум, что может обоснованно знать прикладник - нужны ему все записи или нет.
Для фетча по-одной записи есть SELECT WITH LOCK. Остальное и так давно есть в клиенте.
Единственное, что можно было бы изменить - поднять макс размер пакета.
27 фев 19, 19:55    [21821082]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
hvlad
rdb_dev,

а теперь отключи у клиента
Ну что - бла-бла-бла ? :)
27 фев 19, 19:56    [21821084]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6851
rashid.abzalov,

я не сильно возражаю против задания размера префетча (числа записей) со стороны клиента, если уж этого так сильно хочется. В конце концов, вроде такое есть в JDBC. И вроде не должно быть сложно сделать. Но вот аргументация в тикете никакая, пардон. На 90% там написано то, что fbclient и так делает.
27 фев 19, 20:09    [21821089]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
Dimitry Sibiryakov
Фигнёй эти костыли маются.

Да, ладно. На наших простых тестах select с указанием prefetch (~200-300 записей) ускоряет выборку всего запроса минимум на 20-30%. Конечно это зависит от самого запроса, вернее возможности сервера подготавливать записи так быстро как это запрашивает клиент.

И да, клиентская библиотека посылает запрос на новую порцию данных ещё до того, как полностью отдаст приложению старую.

А вытаскивает из буфера сокета (recv) асинхронно или только при запросе следующей порции данных? Это важно в случае многопоточной работы через одно соединение, т.к. входящий буфер WinSock для этого сокета рано или поздно переполнится.
27 фев 19, 20:14    [21821093]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
rashid.abzalov
На наших простых тестах select с указанием prefetch (~200-300 записей) ускоряет выборку всего запроса минимум на 20-30%

Как в Oracle, так и в Postgres.
27 фев 19, 20:15    [21821094]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
hvlad
Никто никогда не скажет чем префетч N записей лучше префетча M записей.
Максимум, что может обоснованно знать прикладник - нужны ему все записи или нет.

Зависит от задачи. А при отсутствии возможности настройки - да, прикладнику ничего не остается как полагаться на подобранные "оптимальные" (считай усредненные значения) захардкоженные значения параметров.

Для фетча по-одной записи есть SELECT WITH LOCK. Остальное и так давно есть в клиенте.

Lock из другой оперы, здесь он никак не нужен. Никто не собирается фетчить из селективной процедуры, изменяющую данные, записи большими порциями.
27 фев 19, 20:24    [21821100]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rashid.abzalov
Для фетча по-одной записи есть SELECT WITH LOCK. Остальное и так давно есть в клиенте.

Lock из другой оперы
Тьфу, SELECT FOR UPDATE конечно же.
И это никак не связано с блокировками и апдейтами.
27 фев 19, 20:26    [21821102]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
dimitr
Но вот аргументация в тикете никакая, пардон. На 90% там написано то, что fbclient и так делает.

Спасибо, подправил тикет.
27 фев 19, 20:42    [21821115]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Ivan_Pisarevsky
Member

Откуда: НН
Сообщений: 8285
rashid.abzalov
Никто не собирается фетчить из селективной процедуры, изменяющую данные, записи большими порциями.
"Селективная процедура изменяющая данные" - вполне достаточно, что бы выписать написавшему "линейкой по пальцам" в назидательных целях.
27 фев 19, 20:59    [21821120]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
Ivan_Pisarevsky,
Ладно, ладно, так лучше - "Селективная процедура изменяющая данные в автономной транзакции" :)
27 фев 19, 21:22    [21821132]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9475
rashid.abzalov,

а зачем? Лично мне в голову приходит только одна причина использования автономок - логирование ошибок.
В остальном писать в БД что-то не отменяемое кажется странным.
27 фев 19, 21:38    [21821138]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
Симонов Денис,

Вообще-то это была шутка юмора.

Тот кто будет устанавливать большое значение параметра prefetch count, и использовать селективную процедуру, изменяющую данные, да еще и в автономной транзакции - сам себе буратино.
27 фев 19, 21:58    [21821149]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47399

rashid.abzalov
На наших простых тестах select с указанием prefetch (~200-300 записей) ускоряет выборку
всего запроса минимум на 20-30%.

То есть когда ты заставляешь Оракула делать то, что Firebird делает и без пинка под зад,
он внезапно начинает работать быстрее? Ну так тебе надо в трекер Оракула чтобы они
наконец-то включили этот префетч по умолчанию, а не в трекер Firebird для его выключения.

Posted via ActualForum NNTP Server 1.5

27 фев 19, 22:11    [21821162]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
Dimitry Sibiryakov,

Не надо передергивать. Никто не говорил о возможности выключения этой настройки.

Речь о возможности кастомизации в необходимых случаях. Сила неестественного интеллекта это конечно хорошо, но всего не предусмотришь. Так почему бы не предоставить право выбора пользователю?
27 фев 19, 22:40    [21821177]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47399

rashid.abzalov
Так почему бы не предоставить право выбора пользователю?

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

Posted via ActualForum NNTP Server 1.5

27 фев 19, 23:13    [21821198]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2654
hvlad
hvlad
rdb_dev,

а теперь отключи у клиента
Ну что - бла-бла-бла ? :)
Разбудил в VirtualPC "Хрюшу", положил в ней рядом с fbclient.dll файл firebird.conf, где TcpNoNagle = 0, запустил IBExpert, запрос тот же - результат:
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 0ms
Среднее время на получение одной записи = 0.00 ms
Current memory = 18 160 840
Max memory = 18 285 648
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 6

Перезапустил на "хосте" FirebirdSQL сервер, на "госте" повторил процедуру - результат:
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 10ms
Среднее время на получение одной записи = 10.00 ms
Current memory = 18 090 368
Max memory = 18 196 520
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 6

ЧЯДНТ?
28 фев 19, 09:52    [21821404]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rdb_dev
Разбудил в VirtualPC "Хрюшу"...
ЧЯДНТ?
Споришь о том, чего не знаешь :)

Берём настоящую сеть, а не виртуальную. Клиент - на ноуте.
FB 2.5
На клиенте TcpNoNagle = 1

SQL> set stat;
SQL> select 1 from rdb$database;

CONSTANT
============
1

Current memory = 34604704
Delta memory = 102888
Max memory = 34620888
Elapsed time= 0.01 sec

На клиенте TcpNoNagle = 0

SQL> select 1 from rdb$database;

CONSTANT
============
1

Current memory = 34604704
Delta memory = 102888
Max memory = 34620888
Elapsed time= 0.32 sec
28 фев 19, 11:09    [21821495]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rdb_dev
положил в ней рядом с fbclient.dll файл firebird.conf, где TcpNoNagle = 0
Для FB 2.5, кстати, firebird.conf должен быть на каталог выше клиента
28 фев 19, 11:26    [21821510]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10270
rdb_dev,

и напоследок: используя VBox вижу, что если у гостя сеть настроена как NAT, то TcpNoNagle ни на что не влияет, а вот если сеть настроена как мост - очень даже влияет.
28 фев 19, 11:45    [21821530]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2654
hvlad
Берём настоящую сеть, а не виртуальную.
Сеть не причем.
+ В isql, действительно, всё честно:

Use CONNECT or CREATE DATABASE to specify a database
SQL> set sql dialect 3;
SQL> set stat;
SQL> connect 172.31.127.1/3050:testdb user sysdba password masterke;
Database: 172.31.127.1/3050:testdb, User: sysdba
SQL> select rand() from oneRow;

RAND
=======================
0.4407087140997358

Current memory = 17874248
Delta memory = 188712
Max memory = 17950744
Elapsed time= 0.21 sec
Buffers = 2048
Reads = 39
Writes 0
Fetches = 348
SQL> select rand() from oneRow;

RAND
=======================
0.05836457975277807

Current memory = 17874248
Delta memory = 0
Max memory = 17950744
Elapsed time= 0.23 sec
Buffers = 2048
Reads = 0
Writes 0
Fetches = 6
SQL> select rand() from oneRow;

RAND
=======================
0.2575905584690388

Current memory = 17874248
Delta memory = 0
Max memory = 17950744
Elapsed time= 0.20 sec
Buffers = 2048
Reads = 0
Writes 0
Fetches = 6
Адрес 172.31.127.1 на "Microsoft Loopback Adaptor" в Win7, который служит ethernet мостом для WinXP в VirtualPC.

hvlad
rdb_dev
положил в ней рядом с fbclient.dll файл firebird.conf, где TcpNoNagle = 0
Для FB 2.5, кстати, firebird.conf должен быть на каталог выше клиента
Да, уже прочёл на форуме ibase, но таже самая загруженная в IBExpert клиентская библиотека fbclient.dll фигачит:
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 0ms
Среднее время на получение одной записи = 0.00 ms
Current memory = 18 200 256
Max memory = 18 403 872
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 6
И задержки в 1/5 секунды не заметно даже "на глаз". Почему так происходит?
28 фев 19, 11:59    [21821550]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2654
hvlad
rdb_dev,

и напоследок: используя VBox вижу, что если у гостя сеть настроена как NAT, то TcpNoNagle ни на что не влияет, а вот если сеть настроена как мост - очень даже влияет.
У меня ethernet мост через "Microsoft Loopback Adapter" (он же "Адаптер Microsoft замыкания на себя").
28 фев 19, 12:02    [21821557]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rashid.abzalov
Member

Откуда:
Сообщений: 106
Dimitry Sibiryakov
Во-первых, у него просто нет возможности сделать осмысленный выбор.

Под пользователем имелся ввиду прикладник, а конечный пользователь.
5 мар 19, 00:33    [21824942]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 26 27 28 29 30 [31] 32 33 34 35 36   вперед  Ctrl
Все форумы / Firebird, InterBase Ответить