Мимопроходящийсильно подозреваю, что не со старым клиентом.

Точнее даже и не со старым движком, но что если поступить как pgbouncer и
разнести их по разным "внутренним" коннектам вплоть до коннектов к разным нодам
кластера?..
Posted via ActualForum NNTP Server 1.5

Коннект стоит рихтовки рук того заскорузлого паренька, что колбу держит
приложение пишет. Жонглировать несколькими коннектами для повешения общей
производительности приложения не всякая Наталья Хлопотун (тм) осилит, а в
ограничения, накладываемые таковым жонглированием "за кулисами", оно, авось,
как-нибудь само случайно уложится.
Posted via ActualForum NNTP Server 1.5

kdvДальше-то что.

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

Многопоточность - очень крышесдвигающая вещь.
Posted via ActualForum NNTP Server 1.5

Basil A. SidorovЦелью является повышение производительности (условные DML per second)

Это да, но основная проблема тут в том, что Firebird API синхронное, то есть при
возврате из функции ожидается, что она таки выполнена и даже на сервере. Если,
например, заставить Prepare возвращаться сразу как только запрос отослан на
сервер, то сообщение о синтаксической ошибке в этом запросе может вылезть аж на
Fetch, а в результате "DML per second" всё равно не увеличится, поскольку
приложение не готово посылать новый запрос раньше, чем получит результат
предыдущего.

Чтобы оно было готово, его нужно перековывать на использование какого-нибудь
IBatch, но даже там могут быть свои нюансы (я ещё на этот интерфейс вообще не
смотрел).

Поэтому с точки зрения приложения проще запустить несколько потоков, которые эту
фигню разрулят "автомагически". Но на данный момент этот подход означает
отдельный коннект на каждый поток. Что, как справедливо заметил Дед, приемлемая
цена.

Мой же вопрос состоит в том можно ли получить какую-нибудь дополнительную
прибыль в DML/s, заставив эти потоки щемиться в одну дверь (и разведя их по
отдельным кабинкам уже на сервере) вместо пробития каждому индивидуальной.

Бонус-условие: сервер находится в облаке с доступом через Internet, то бишь
канал с повышенной латентностью. (В данный момент Firebird слаба на этом рынке.)
Posted via ActualForum NNTP Server 1.5

Basil A. SidorovНа "этом рынке" слаба не Firebird, а двухзвенная архитектура.

Да. И именно эту проблему хочется решить.

Basil A. SidorovРешений которые реализуемые уже сейчас - два и они - не
взаимоисключающие.
И вы, как я понимаю, знаете их оба.

Нет, не знаю. То, что я знаю - одно, да и решением, собственно говоря, не является.
Posted via ActualForum NNTP Server 1.5

Basil A. SidorovТрёхзвенка. Да, неуниверсально и требует "много возни".

И самое главное - не работает. Ибо физика та же самая.

Basil A. SidorovПрокси позволит сократить издержки с "задержка на каждое
сообщение" до "задержка на пачку сообщений", уменьшив общее количество
(промежуточных интернет-)подключений.

И вот именно это я сейчас пытаюсь себе уложить в голове. Пока получается не очень.
Posted via ActualForum NNTP Server 1.5