[kim-aa]

А задач в вышеупомянутом примере не одна, а минимум две: сервер 1с и сервер SQL. »

Это не совсем так. Архитектурно сервер RDBS и сервер 1с - разные процессы и сответственно запускать их на одной машине или не на одной уже задача разработчика конфигурации.

Более того

Расположение сервера 1С:Предприятия 8 и MS SQL Server на разных компьютерах позволяет администратору распределять нагрузку между серверами

т.е. для высоконагруженных систем предлагается применять стандартную трехслойную архитектуру ,т.е. физически разносить сервер 1с и MS SQL сервер.

Хочу заметить что в эпоху 7.7, подобная трехслойная схема собиралась из отдельного MS SQL Сервера и отдельного Терминал-сервера где стартовали клиенты 7.7
Собственно Терминал-Сервер эмулировал (или выполнял) роль Application Server стандартной трехслойной архитектуры.
При большом числе клиентов использовалось несколько Терминал-серверов (этакие Инстанции, в терминах SAP R/3).

Однако когда 1С 8х только анонсировалась, то ее главной фишкой называлось появление родного сервера приложений , т.е. Application Server'a

Вот собственно описание архитектуры, http://www.v8.1c.ru/tests/architecture/
и согласно ей введение четвертого слоя ,т.е. Терминал-сервера нафиг не сдалось

[kim-aa]

Кстати вот архитектура 1С 8х. http://www.v8.1c.ru/overview/cluster.htm#WorkingServer
Ни чем, по болшому счету, принципиально не отличается скажем от SAP R/3

Только название "Кластер" они выбрали малость нестандартное, но тут уж кто как извращается.

[kim-aa]

Я, кажется нашел объяснение ускорения работы при применении терминал-сервера.
Вот http://www.v8.1c.ru/disctinct7/indexDevelop.htm

А именно:

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

Т. е. это стандартная ситуация криворукости разработчиков на уровне Application, которые заставляют выполнятся код на стороне клиента.

[kim-aa]

Вот еще
http://www.v8.1c.ru/overview/CommonC...ant.htm#Server

Работа встроенного языка на сервере При работе в клиент-серверном варианте разработчик может организовать выполнение различных процедур и функций общих модулей и модулей объектов на сервере приложения или на клиентском месте. Для этого используются свойства модулей и операторы препроцессора #Если Сервер Тогда ... #КонецЕcли и #Если Клиент Тогда ... #КонецЕсли:

Из всего вышепревиденного следует:
-- Редкие эротические фантазеры эти господа из 1С
-- Клиент 1С, как был толстым, так и остался. Просто добавлена возможность часть кода выполнять на сервере.
-- В виду того что администратор физически не может проверить весь код на "Правильность", т.е. наличие директив явного выполнения кода на Сервере 1С, в крупных системах требуется или наличие Терминал-сервера или Монстра-разработчика которому будет не впадлу перелопачивать весь код на предмет включения директив явного выполнения на сервере.
Ситуацию ухудшает наличие наследственности, т.е. хреновой темени кода перенесенного кабы еще не с Шестерки.
-- Господа из 1С таки редкие звездуны.

[dascon]

В системе Win32, процессу более 2 ГБ ОЗУ не выделяется, технически (Это не зависит ни от версии сервера, ни от системных настроек, -это архитектурные ограничения)

здесь, вроде, рекомендации как выделить для Oracle более 2Гб.
MS SQL и без этого 8Гб жрет молча (у него, видимо, свои отношения с операционкой).

[kim-aa]

здесь, вроде, рекомендации как выделить для Oracle более 2Гб. »

Это конечно все хорошо, только жизнь портит эта маленькая строчка:

One limitation here is that Oracle can do it only for buffer cache, not shared pool.

remember, that SGA and PGA come from the same address space. So, do not set your SGA to 3GB - you will have no memory for client processes then.

Т. е. возможно выделить память свыше 2х ГБ только под кэш чтения/записи.
Однако именно для пользовательских процессов Oracle или внутриситемных целей Oracle выше 2х ГБ выделить не получится.

У MS SQL скажем прямо, совсем иная архитектура, которая привязана именно к модели потоков (thread) Win.
Естественно он более эффективно использует память на родной 32-битной платформе, но именно по этому перенести его на иные платформы малость затруднительно.