Доброго времени суток. Есть клиент который берёт БД на удалённой машине (делает запросы SELECT). На удалённой машине поднят IBASE сервер. Полученные данные из запроса преобразовывает и записывает в другую БД, которая находится на локальной машине. Весь процесс протекает крайне долго. Я так понимаю, это происходит из-за того, что запросы к удалённой машине (к ней и от неё) происходят с огромной задержкой связанной с маленьким объёмом передачи данных. Замечал, что запросы к БД с более "весомыми" полями происходят быстрее, но всё равно очень медленно. Как можно ускорить этот процесс? Настройки сервера ?

Я программист. Пишу код и столкнулся с этой бедой. Сервер (СУБД) interbase 6.5.

Хорошо. Я пишу код. Так пойдёт ?
Зачем мне упаковывать в свой формат, отправлять на удалёнку и там зашивать ? Это же должен делать сервер, накой он нужен тогда.

Нет. Комп стоит в 20 м от меня.

Для Мимопроходящий . Сервер (удалённая машина) находится в одной локальной сети с моим (мой - это тот на котором запускаю клиента) компом

Нет. Ты не прав. Тогда всё удалось ускорить. И тогда не использовалась сеть вообще.
Сейчас, если работаю с БД находящейся на локальной машине то скорость вполне устраивает. Но взаимодействие серверов interbase по сети происходит жутко медленно . Сервера interbase тупо не вызывают flush() для отправки сетевого пакета, ждут когда накопятся данные, а клиент которые шлёт данные ждёт сервера (взаимоблокировка), в итоге flush вызывает супервизор (по таймеру), от этого всё зло ИМХО.

Наконец-то нормальные адекватные люди посетили эту страничку и дали дельные советы и замечания. За это всем спасибо.
rdb_devAbraziv, попробуйте, для начала, перевести сетевые адаптеры на сервере и клиенте в режим приемопередачи "полудуплекс" (half duplex). Если ситуация улучшится, значит проблема где-то на физическом уровне. Если ситуация не изменится или ухудшится, то верните настройку обратно и попробуйте поиграть значением настройки Interbase'а - TCP_REMOTE_BUFFER (1448 - 32768).
Сейчас возможно попробовать нет, завтра по тестирую.
rdb_devНе забывайте, что операционная система также может отдавать данные основываясь на Nagle-алгоритме. Interbase сервер на Windows?Да, на Windows (тестил на 7 и server 2003).
Граур СтаниславAbrazivДоброго времени суток. Есть клиент который берёт БД на удалённой машине (делает запросы SELECT). На удалённой машине поднят IBASE сервер. Полученные данные из запроса преобразовывает и записывает в другую БД, которая находится на локальной машине. Весь процесс протекает крайне долго. Я так понимаю, это происходит из-за того, что запросы к удалённой машине (к ней и от неё) происходят с огромной задержкой связанной с маленьким объёмом передачи данных. Замечал, что запросы к БД с более "весомыми" полями происходят быстрее, но всё равно очень медленно. Как можно ускорить этот процесс? Настройки сервера ?

DDL таблицы из которой делается SELECT.
Код SQL-запроса.

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

Очень медленно - это годы, дни, секунды?
Скорость сети?
По сети файл размером в несколько Гб копируется на эту "удаленную машину" за адекватное время?

Ускорить процесс можно излагая факты, а не поток сознания.
Всё верно говорите. Сейчас не получится привести запросы и код. Но скажу следующее, если бы дело было в коде, то тормозило бы и на локальной обработке (обе БД на локале), как я говорил выше локальные БД обрабатывает на ура.
По скорости скажу так, обрабатывается ~1 MB в с, т.е. открывается БД на локале и перегоняется на удалёнку.

Хотел ещё дополнить. Видно, что данные передаются дискретно с одинаковым периодом.

Дай угадаю: опять каждый запрос в отдельной транзакции и prepare в цикле. В морг.
Нет. 2000 запросов в одной транзакции. Сам иди.
Это ничего, что ИБ6 умер за несколько лет до выхода означенных виндовсов? ИБ6.5 это 2001 год, вин7 это 2009 год.
Использую IB 2009, с IB6 я погорячился.

Эмпирически установил, что больше 400 запросов в одной транзакции улучшает производительность. Поставил 2000.

Завтра попробую это
https://support.microsoft.com/ru-ru/kb/138831

Dimitry Sibiryakov
Есть другой путь?