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

Откуда: PNZ
Сообщений: 6876
Во-первых, для начала можно было почитать тут, а уже потом постить.
Во-вторых, если клиентская либа закешировала N записей, в чем архи-полезность возвращать их по индексу, а не последовательно?
27 фев 19, 08:09    [21820166]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
hvlad
Dimitry Sibiryakov
Ну и спойлер на сладкое: из-за
полного квитирования в Firebird протоколе её выключение ничего не изменит.
Ну да, разве что будешь ждать на 200мс дольше на каждый вызов.
Кроме того, в случае, когда после отправки пакета софт переключает сокет в режим ожидания входящего пакета, никакого ожидания в 200мс не будет - исходящий пакет сразу улетит до получателя.
27 фев 19, 10:02    [21820223]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
dimitr
Во-первых, для начала можно было почитать тут, а уже потом постить.
Во-вторых, если клиентская либа закешировала N записей, в чем архи-полезность возвращать их по индексу, а не последовательно?
Дмитрий, это ты про моё предложение?
В моём предложении на клиента прилетает только ROWSET_ID, а чтобы получить записи по этому идентификатору, надо привычно прогнать SP/EB с SUSPEND'ом. Следовательно, на клиента просто прилетит кучка записей без всяких индексов.
27 фев 19, 10:07    [21820227]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6876
rdb_dev
Дмитрий, это ты про моё предложение?

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

Откуда:
Сообщений: 10529
rdb_dev
hvlad
Ну да, разве что будешь ждать на 200мс дольше на каждый вызов.
Кроме того, в случае, когда после отправки пакета софт переключает сокет в режим ожидания входящего пакета, никакого ожидания в 200мс не будет - исходящий пакет сразу улетит до получателя.
Откуда такие предположения ?
И что такое "переключает сокет в режим ожидания входящего пакета" ?
27 фев 19, 11:10    [21820297]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
hvlad
Откуда такие предположения ?
Предлагаю не верить мне наслово, а проверить самостоятельно на форточках от XP до 10-ки. ;) За *nix'ы не скажу - не проверял.

hvlad
И что такое "переключает сокет в режим ожидания входящего пакета"?
Выполнение recv после send.
27 фев 19, 11:38    [21820312]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

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

ну так отключи TcpNoNagle и предъяви результаты.
Клиент вызывает recv сразу после send, если чё
27 фев 19, 11:46    [21820323]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
hvlad
Клиент вызывает recv сразу после send, если чё
Как правило - да, но так бывает не всегда. Зависит от особенностей реализации приложения.
27 фев 19, 11:56    [21820340]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6876
rdb_dev
Как правило - да, но так бывает не всегда

мы про сферический клиент в вакууме или все-таки про fbclient?
27 фев 19, 11:58    [21820347]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
dimitr, про сферический клиент в вакууме, конечно же. Пока не изучал реализацию fbclient'а... У него есть какие-то принципиальные отличия?
27 фев 19, 12:06    [21820361]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 9811
rdb_dev,

отличия от кого? Без fbclient могут работать не так уж много библиотек Java, .Net, некоторые реализации NodeJS и IBProvider.
Ты ещё что-то знаешь, или собственный клиент запилил?
27 фев 19, 12:09    [21820365]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 6876
rdb_dev
dimitr, про сферический клиент в вакууме, конечно же

тогда форумом ошибся
27 фев 19, 12:14    [21820370]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
Симонов Денис, алгоритм работы Беркли сокетов и стека TCP/IP никак не связан с реализацией конкретного клиента для конкретного сервера, использующего эти сокеты. Да, ты можешь задать некоторые допустимые параметры сокета, которые могут влиять на некоторые реализации клиентов и серверов, например, при потоковой передачи видео, но, согласись, бессмысленно ожидать 200мс после send->recv.
27 фев 19, 12:24    [21820384]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Arioch
Member

Откуда:
Сообщений: 10958
Dimitry Sibiryakov
что каналу (физическому) сугубо всё равно "пустая"
несущая передаётся или с битами.


....но это ,если передаётся. А может ведь не передаваться, а отключиться.
27 фев 19, 12:32    [21820396]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 10529
rdb_dev
про сферический клиент в вакууме, конечно же
Снова игра в мир-дверь-мяч...
Игнор на месяц, минимум
27 фев 19, 12:35    [21820407]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Дегтярев Евгений
Member

Откуда: Барнаул
Сообщений: 1642
Симонов Денис
rdb_dev,
Без fbclient могут работать не так уж много библиотек Java, .Net, некоторые реализации NodeJS и IBProvider.
Ты ещё что-то знаешь, или собственный клиент запилил?

github.com/nakagami/firebirdsql, но там так же write -> read
27 фев 19, 13:02    [21820451]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

rdb_dev
согласись, бессмысленно ожидать 200мс после send->recv.

Не соглашусь. Сокеты - полнодуплексная штука. У них запись и чтение никак не связаны.
Более того, один поток может постоянно висеть на recv() пока остальные только и делают,
что вызывают send(). И при этом отсылаемые ими данные вообще не порождают ответов. Это
уровень приложения о котором транспортный ничего не знает.

Posted via ActualForum NNTP Server 1.5

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

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

ну так отключи TcpNoNagle и предъяви результаты.
Клиент вызывает recv сразу после send, если чё
Легко!
FirebirdSQL 2.5 WI-V6.3.9.27.110, в конфиге сервера (firebird.conf) TcpNoNagle = 0
Подключаюсь IBExpert'ом из VirtualPC (WinXP SP3) и выполняю простой запрос:
SELECT RAND() FROM oneRow
------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 0ms
Среднее время на получение одной записи = 0.00 ms
Current memory = 18 721 264
Max memory = 19 143 808
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Чтений из кэша = 6

Если допустить, что сам клиент использует параметр TCP_NODELAY для открываемого сокета, то, хотябы, сервер должен был выждать 200мс перед тем как фактически послать пакет, ведь отправляемый сервером пакет с результатом вряд ли больше 1500.
27 фев 19, 13:40    [21820502]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
rdb_dev
Member

Откуда: с болот
Сообщений: 2929
Dimitry Sibiryakov, сериализация операций ввода/вывода из разных потоков по одному и тому же хендлу на уровне библиотеки сокетов не означает, что ты параллельно из разных потоков можешь выполнить send и recv. Даже если ты переведешь сокет в неблокируемый режим, то он тебе просто вернёт ошибку при невозможности выполнить операцию чтения/записи, после чего ты должен будешь попытаться повторить операцию. Хотя чуть ниже за сокетами (на стеке TCP/IP), да - вполне себе полный дуплекс.
27 фев 19, 14:42    [21820621]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

rdb_dev
не означает, что ты параллельно из разных потоков можешь выполнить send и recv

Чувак, я его выполняю. Весь FireSwarm на этом построен.

Posted via ActualForum NNTP Server 1.5

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

Откуда: с болот
Сообщений: 2929
Dimitry Sibiryakov, единовременно может выполняться лишь одна коллективная операция. К примеру, функция send реально никаких данных не отправляет и не гарантирует, что после её выполнения данные будут доставлены получателю, а лишь передает данные для отправки на уровень стека TCP/IP и пока выполняется функция send, никакой другой поток по тому же хендлу не сможет успешно выполнить функцию recv, но после того, как функция send успешно завершена, функция recv может быть успешно выполнена, так как стек TCP/IP параллельно может отправлять и получать данные в пределах установленного TCP соединения.
Асинхронный ввод-вывод средствами POSIX
27 фев 19, 15:16    [21820706]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
Dimitry Sibiryakov
Member

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

Ты опять постишь многа букаф и ссылки на статьи для чайников без реального понимания того
что там написано.

Posted via ActualForum NNTP Server 1.5

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

Откуда: с болот
Сообщений: 2929
Dimitry Sibiryakov, возможно, как ты утверждаешь, я ничерта не понимаю в handle-ориентированном вводе/выводе...
Хорошо! Когда у меня будет чуть больше времени, постараюсь сбацать test case с двумя потоками и spin-wait'ом, чтобы функция send для блокирующего сокета с отправкой большого блока данных стартовала на мгновение раньше функции recv с получением уже присланного маленького блока данных и посмотрим - будет ли функция recv на том же описателе висеть в ожидании, пока функция send занимается обработкой передачи данных на уровень стека TCP/IP или же отработает параллельно.
27 фев 19, 15:45    [21820769]     Ответить | Цитировать Сообщить модератору
 Re: Конкурс идей про Firebird  [new]
hvlad
Member

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

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

Откуда:
Сообщений: 108
hvlad
Batch API

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