Yo.!pkarklinЯ правильно понимаю, что если я не могу контроллировать количество открытий\закрытий подключений на стороне клиента, то единственный мой путь - это трехзвенка с коннешен пулом на "апп" лайере?
нет. можно кол-во диспатчеров поднять, можно коннектится к пулу оракла, можно вообще оракл в режиме MTS запустить.

Если бы сервер работал в шаред режиме, который вы назвали мтс, то этого топика вообще не возникло бы. Товарищ не сумел бы заметить разницы и радовался.

2praklin
По умолчанию оракл ставится вдедикейтед режиме, где, в случае винды для каждого клиентского соединения образуется отдельный поток на сервере, в слуёае с не виндой - обычно отдельный процесс. При этом с резервом памяти под хранение контекстов и прочих сессионных глобалов. Просто представьте - на жалкий писюк обрушивается 400 независимых потоков, жестко конкурирующих за процессор. Система ляжет задолго до того, как свал-тся в глухой своп. Просто добавьте активных соединений и возрадуйтесь от уклабывания на лопатки. Это обыкновенное са?осбывающееся пророчество.

Это до разбора с разницами в устройстве собственно движка бд.
Программировать в стиле топикстартера дедикейтед сетвер мтжно с единственной целью - предоставить заказчику прямые убедительные доказательства того, что с ораклом работать вообще нельзя.
Сорри - это первая попытка писать с телефона, поэтому бкксы прыгают.

pkarklin,

Попробуем выявить разницу.
Сначала э- как получается 960:
32 процессора х 8 ядер х 2 гипертрединг = 480 логических железных потоков
т.е. 480 процессоров с точки зрения софта.
960 это всего два софт потока на каждый хард поток.
В шаред режиме сервер резкрвирует себе диапазон, в котором на данном железе достигается макстмальный суммарный пропускной поток производительности, который нельзя деградировать.
Пусть теперь есть 100500 соединений, каждое из которых затребовало немедленной работы.
В шаред режтме, грубо, это просто список, очередь, отмапированная на рабочие потоки. Здесь нельзя повредить суммарной производ-тельности сервера методом развития чрезмерной конкуренции за процессор. В дедикейтед режиме этореальные потоки-процессы, реально конкурирующие за доступ к процессору.
Да, клиент в обоих случпях будет видеть ухудшение времени отклика. Но в случае дедикейтед сервера ситуация становится катастрофической, т.к. ищ-за конкуренции страдает суммарная пропускнаяспособность сервера.