Каждому клиенту 1С по серверу приложений, на том же самом компьютере, что будет?

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

На каждом достаточно мощном компьютере устанавливаем вместе с клиентской частью 1С сервер приложений, вместе с лицензией на него. Понятно, что какого-то клиента с его сервером приложений делаем «более равным», т.е. назначаем этому компьютеру роль центрального сервера для кластера серверов. Таким образом, вместо трезвенной архитектуры:

[Клиент 1С] – [Сервер приложения 1С] – [SQL Сервер базы данных],

фактически получаем два уровня:

[Клиент 1С + Сервер приложения 1С] – [SQL Сервер базы данных].

В этом случае не важно, какой у нас клиент, толстый или тонкий. Интересует только вопрос производительности. Сколько таких объединенных клиентов способна выдержать гигабитная сеть при достаточно мощном сервере базы данных? И будет ли такая планировка работоспособной? Какие технические нюансы возникнут при этом?

Согласен с тем, что данная схема не до конца изложена. Исходим из того, что нам нужно реализовать эту конструкцию в принципе. Для этого привлекаем технических специалистов, которые говорят, как этого доиться, безотносительно к целесообразности и стоимости проекта. Поэтому первый вопрос, как доиться реализации подобной связки чисто технически?

Вот читаем документацию: «Клиент-серверный вариант. Руководство администратора», 2013. (Кстати, в ней ничего не говориться про «монитор транзакций», т.е. это внешний инструмент, в принципе, не обязательный.) В данной книге говориться, что пусть:

«Центральный сервер адресуется как 1С_Serv:1540. Кластер, расположенный на этом сервере, адресуется как 1С_Serv:1541, а рабочий процесс – 1С_Serv:1561. Когда клиентское приложение пытается подключиться к информационной базе в варианте клиент-сервер, оно обращается по адресу кластера серверов: 1С_Serv:1541. Менеджер кластера выбирает рабочий процесс, который будет обслуживать клиентское приложение, и сообщает клиентскому приложению его адрес.»

Если:

«Рабочий процесс один, это будет 1С_Serv:1561. Клиентское приложение связывается с выделенным ему рабочим процессом, который выполняет аутентификацию пользователя информационной базы и осуществляет все дальнейшее взаимодействие клиентского приложения с информационной базой.»

Теперь вопрос, разве рабочий процесс (1С_Serv:1561) нельзя выполнять на клиентском компьютере? В идеале, вообще не обращаться к менеджеру кластера, поскольку рабочий процесс будет запушен на том же самом компьютере. Ну, если надо прописать всю конфигурацию заранее статически, то не вопрос.

Таким образом, задача не в том, чтобы доказать, что подобная технология в принципе технически невозможна, а как раз наоборот, что принципе технически возможна.

В данном случае меня интересует не столько вопрос масштабирования, столько внутренняя архитектура «черного ящика», коим является кластер (или кластера, в общем случае?) серверов приложений. Можно считать, что это просто мысленный технический эксперимент, чтобы выяснить работоспособность серверов приложений в экстремальной ситуации.

Фирма «1С» скрывает «внутренности» своей архитектуры, что приводит иногда к казусам. Смотрите интервью руководителя корпоративных проектов ОАО «КАМАЗ» Рустема Авхадиева – «КАМАЗ: автоматизация на базе “1С” . Вот, что он говорит в интервью:

ИнтервьюPC Week: С учетом масштабов бизнеса КАМАЗа (миллион проводок в день) производительность внедряемых решений особенно критична. Сталкивались ли вы с проблемой недостаточной производительности в процессе эксплуатации решений “1С”?

Р. А.: Да, сталкивались. Был момент, когда в 2010-м задержка в проведении документов, введенных в систему, достигла месяца.

PC Week: С чем была связана данная проблема и как она была разрешена?

Р. А.: Дело в том, что в типовой конфигурации никакой системой миллион проводок в день не обработаешь, причем, по моему мнению, какую бы платформу вы ни применяли — “1С” или другого вендора. С проблемой мы справились, сформировав трехстороннюю команду поддержки внедрения, в которую вошли представители предприятия, партнера и “1С”. Совместными усилиями вопрос был решен, причем весьма быстро — за один-два месяца. А проблема сама по себе была, как говорят программисты, низкоуровневая: мы не знали “внутренностей” системы, каким образом она обрабатывает запросы, как записывает данные. Но прошли специальный курс обучения и успешно оптимизировали систему на уровне кода (формирование запросов, блокировка пользователей при совместном обращении к одним данным и так далее), решив таким образом задачу повышения ее производительности.
Т.е., для того, чтобы эффективно внедрять «1С» надо «пройти специальный курс обучения и успешно оптимизировать систему на уровне кода» . На Камазе для этого привлекли как саму фирму «1С», так и «75 специалистов из компании “Интелком” — стратегического партнера по внедрению таких решений». И это не считая десятка штатных специалистов «1С» самого Камаза.

Причем, здесь видно логическое противоречие, с одной стороны: «никакой системой миллион проводок в день не обработаешь» , а с другой «вопрос был решен, причем весьма быстро» .

Думаю, что если бы подобный «специальный курс обучения» был бы опубликован, то вопросов в этом топике было бы меньше.

trewКластер 1С всегда один, для конкретной информационной базы (ИБ). В него могут входить несколько физических серверов.
Хорошо, если так, а то я где-то читал о «кластерах серверов» для одной ИБ.

trewЕсли будет несколько серверов приложения 1С для одной ИБ:
1) администрирование трудно осуществлять
2) отслеживание блокировки ресурсов, её не будет на кластере 1С. Вся надежда будет только на сервер базы данных, его блокировки.
Например, управляемые блокировки 1С на кластере проходят контроль.
Моя задача разобраться в архитектуре и принципах работы кластера серверов приложения 1С несколько глубже, чем это описано в общедоступных источниках информации.

«Трудно осуществлять» это не повод ограничиться только одним сервером приложений. Блокировки на сервере приложений относятся скорее к административной логике (наряду с бизнес логикой) информационной базы. По сути, сервер приложений это всего лишь промежуточный программный слой (между клиентом и сервером) вынесенный наружу. В различных видах клиент-серверных технологий (только классических не менее пяти), этот промежуточный слой может быть распределен между клиентом и сервером в достаточно произвольном порядке. В идеале этот слой наиболее эффективен, если он принадлежит серверу базы данных. Хотя при этом программировать труднее.

Ведь как пишут в технической литературе: «Программирование бизнес логики на стороне SQL-сервера это “хлеб и масло” работы программиста баз данных». Смотрите, с SQL-сервером программисту можно работать с двух крайних позиций: «параллельной» и «перпендикулярной».

«Параллельная» работа означает использование в основном обычных и расширенных хранимых процедур (внешних dll), со специфической бизнес логикой, при этом клиент остается «тонким» (главная работа сводится к вызову этих процедур), а технология – двухуровневой.

«Перпендикулярная» работа означает интенсивное использование внешних запросов со стороны программиста либо его «представителя» – «толстого» клиента либо промежуточного сервера приложения, как это сделано у «1С». Т.е. при трехзвенной работе, основная мощь SQL сервера попросту не задействуется, а используются просто как хранилище данных. Поэтому «1С» все равно, с чем работать, хоть с MS SQL Server 2000, хоть с MS SQL Server 2014. Общие принципы работы в основном одни и те же.

Истина, вообще говоря, «лежит посередине». Однако общее впечатление, что 1С8х не столько технологическое, сколько коммерческое решение, где пользователя заставляют платить большей частью за ПОНТЫ, давая при этом некоторые возможности решать задачи по существу, но за большие деньги :) .

Например, в версии 8.1 «толстый» клиент был «хорошим», потому, что другого не было, а начиная с версии «8.2» он вдруг стал «плохим», поскольку появился «тонкий» клиент. Как там, в рекламе, новое средство всегда лучше старого, только потому, что новое.

Своим мысленным техническим экспериментом, я хотел продемонстрировать техническую неоднозначность «тонкого» клиента. Чем скажем тонкий клиент плюс сервер приложений лучше толстого клиента плюс сервер терминалов? Только тем, что фирма «1С» не автор сервера терминалов?

У меня нет желания сводить все к критике «1С», сильные стороны у нее тоже есть и немало. Просто, повторю, мне хочется глубже узнать «архитектуру и принципы работы кластера серверов приложения 1С», только и всего.

trewПочему вы решили что Сервер приложения 1С - это узкое место производительности работы?
А Вы полагаете, что «узкое место» это сервер базы данных? Или «тонкий» клиент? Фактически сервера приложений это клиенты (одного!) сервера базы данных. А насколько эти клиенты делают «хорошие» или «правильные» запросы к серверу БД, это большой вопрос.

СисойНе взлетит. Работа с двух серверов приложений с одной БД приводит к разрушению БД. Проверено на практике.
Вы забываете про кэширование конфигурации и данных на сервере. Страшная штука.
Т.е. Вы хотите сказать, что кластер серверов 1С это фикция? Вероятно, речь идет о том, что это может привести к «разрушению БД», но совершенно не обязательно, если соблюдать «технику безопасности».

Именно о необходимости выяснить архитектуру и принципы работы «черного ящика» – сервера приложений 1С я и веду здесь речь. Фирма Нуралиева утверждает, что нам это не нужно, мол, это для нашего же блага. С этим трудно согласиться. Кому не нужно, пусть игнорирует данную информацию, а остальным приходится исключительно опытным путем через «выбоины и колдобины» выяснять истинную суть вещей. Вот и Вы пишете: «Проверено на практике». Представляю, сколько времени зря потеряно.

СисойВендор дал Вам в руки инструмент - кластер серверов. Для сложных случаев распределения нагрузки дал лицензию ПРОФ.
Дальше Вы можете оптимизировать в двух направлениях:
1. Перенос нагрузки с app server на database server (SQL, собственные триггера). Можно вынести часть данных во внешнюю БД (например, binary data).
2. Разбиение БД на несколько более мелких, затем консолидация или OLAP.
Ну, если я буду сам программировать конфигурацию 1С с нуля, то возможностей оптимизации наверняка будет больше. Однако реально программист 1С как бы не должен уже это делать, поскольку типовые конфигурации в большинстве случаев решают основные проблемы (не будем брать крайние случаи). Максимум, что остается прикладному программисту это делать заплатки на базовом коде типовых конфигураций.

Не буду спорить, кому-то может быть сильно приходится переделывать, скажем, УПП-1.3 или «1С:ERP Управление предприятием – 2.0». Точнее будет сказать, что профессия «программист 1С» вырождается в «специалист 1С». Тот же руководитель корпоративных проектов ОАО «КАМАЗ» Рустем Авхадиев говорит, что у него в подчинении десять программистов 1С, однако их основная задача не программировать, а обеспечивать работу конфигурации «1С:MES Оперативное управление производством», которую внедряли и постоянно поддерживают 75 специалистов «Интелком» из Казани. Может быть, их роль вообще сводиться к помощи интелкомовцам.

СисойКроме того, в текущих конфигурациях 1С многие блокировки программные, исходя из особенностей бизнес-логики, а не так как в 8.0, неявные.
Хорошо, если они сделаны по уму, иначе, придется долго и нудно лазить по коду чужой конфигурации, чтобы находить узкие места.

СисойКлючевой момент: если с БД 1С начинают работать "напрямую", в обход сервера приложений, Вы никак не сможете проинформировать "второй" сервер об изменениях в структуре БД, или в закешированных данных. Кроме рестарта, никаких других способов у Вас нет.
В данном случае речь не шла о нештатной работе клиента с сервером БД. Все штатно. Отличие только в том, что количество серверов 1С не минимально необходимое, а избыточное – по числу клиентов. Не означает же, в самом деле, то, что допустим добавление сверх необходимого еще одного сервера приложений способно обрушить всю систему? Второй момент здесь это интеграция каждого клиента с его «собственным» сервером приложений на том же самом достаточно мощном компьютере.

А если уж работать «напрямую», то нужно полностью отдавать себе, что мы делаем.

СисойВ 8.1 не существовало способа программно перенести нагрузку на сервер, кроме как при помощи серверного общего модуля.
В "тонком" клиенте программист имеет больше возможностей управлять балансировкой нагрузки.
Какого программиста Вы имеет в виду? Того, что пишет типовые конфигурации в специализированных фирмах или сотрудника предприятия, где работает данная конфигурация? Если второго, то, как мне кажется, он не должен, вообще говоря, «управлять балансировкой нагрузки» на уровне программного модуля. Это задача самой платформы и разработчиков типовых решений. А речь, в принципе, идет не о них. К ним, кстати, вопрос особый. Что для них важнее, чтобы конфа худо-бедно работала или, чтобы она демонстрировала максимально возможную производительность при нормальном «железе»? Боюсь, что деньги им платят за необходимость работы их программного кода «вообще», а не «конкретно». По крайней мере, для 1С77 можно было легко значительно повысить производительность, только переписав с нуля типовую конфигурацию под себя, часто в обход всех методических рекомендаций по программированию кода в стиле «1С совместимо». Мое мнение, которое я уже высказывал, что «1С» это в первую очередь коммерческое решение (что типично для многих коммерческих фирм, тот же «Мелкософт») и уже во вторую – техническое.

СисойТак чем же тонкий клиент плюс сервер приложений лучше толстого клиента плюс сервер терминалов? Ну в первую очередь, накладными расходами. Все-таки поддерживать сеанс связи с тонким клиентом и полноценный терминальный сеанс - разные задачи.
Для сервера терминалов тупо нужно больше памяти и дискового пространства.
Если речь идет о локальной сети, то толстый клиент + терминальный сервер это отличное решение. «Накладные расходы» это «мелочи». В этом случае сервер приложений вообще не нужен, он будет только «болтаться под ногами» и мешать. Но чтобы максимально минимизировать его фактор надо знать внутреннюю работу самого сервера приложений или работать на более старых версиях 1С.

Для тонких и веб-клиентов разговор особый. Если бы здесь фирма «1С» пошла по пути MS Visual Studio LightSwitch, то ей бы цены не было. Однако имеем то, что имеем, в этом случае используем традиционное решение с учетом имеющегося опыта, как любят говорить буржуи – «best practices».

СисойСамое главное, для чего 1С сделала тонкий клиент - для браузерной работы. В любом любимом браузере.
Концептуально LightSwitch выглядит в этом смысле более привлекательно, хотя ему еще «без году неделя».

СисойКстати, никто не запрещает работать с БД одновременно и из толстых, и из тонких клиентов - такое есть в УПП, Консолидации и т.п.
Это все так, но остается вопрос избыточной цены за подобное «удовольствие».

ХитроглазыйЭто не фикция, это Вы путаете понятия и сбиваете с толку. Кластер серверов - логическое понятие, под которым подразумевается центральный сервер кластера (rmngr.exe) + рабочие сервера (rphost.exe). Когда говорят "Сервер приложения 1С" подразумевают как раз кластер серверов, а не отдельные рабочие сервера.
Я не против четкости формулировок, просто понятие «Сервер приложения 1С» часто используется во множественном числе для одного решения, что приводит к всеобщей путанице. Вот пример:



ХитроглазыйОтсюда и следствия:
- работать с одной базой несколько серверов приложений корректно не могут;
- рабочий сервер не может работать без менеджера кластера;
Ну, я вообще-то имел в виду рабочие сервера, если придерживаться Вашей терминологии. На «одном, более равном» компьютере пусть размещается центральный сервер, клиент и рабочий сервер, а на всех остальных клиентах только рабочие сервера кластера приложений 1С . Т.е. если говорить именно о «кластере приложений» вместо «сервера приложений», тогда путаницы будет меньше, в этом случае, под «серверами приложений» следует понимать «рабочие сервера». А то слово «сервер» получается слишком перегруженным.

ХитроглазыйС учетом выше сказанного Ваш вопрос стоит задать по-другому:
как можно повлиять на выбор рабочего сервера для каждого клиентского подключения. На сколько мне известно, сейчас такой возможности нет.
Пусть даже так, но не думаю, что это принципиальное ограничение. Просто как всегда фирма «1С» избавила нас от лишней «заботы». Дело в том, что я хотел показать, что трехзвенная архитектура это частный случай двухзвенной, т.е. клиент-серверной. При этом, так называемая, бизнес логика (включающая административную логику и интерфейсную логику) штука весьма подвижная в плане архитектуры. Она может быть распределена (вообще, а не конкретно для 1С) между клиентом и сервером достаточно произвольным образом. Только классических схем клиент-сервера, не менее пяти. Лично я трехзвенку воспринимаю как двухзвенку, со сложным клиентом, состоящих из двух компонентов. Поэтому и проблемы работы 1С я ищу не в сервере БД, а в связке клиент + сервер приложений. А главный вывод для меня состоит в том, что эта связка далека от своего идеала. В этом смысле фирме «1С» более чем достаточно свободы действий для совершенствования ее продукта.

ХитроглазыйИ еще на счет "сервер приложений вообще не нужен" применительно к 1С 8:
транслированием клиентских запросов в SQL-запросы конкретной СУБД, а так же обратным преобразованием реляционных данных в объектную модель занимается исключительно сервер приложения (rphost). Толстый клиент этого попросту не умеет. Разница между тонким и толстым клиентом лишь в том, кто дальше будет работать с этой объектной моделью: серверный (rphost) или клиентский (1cv8)
Это естественно, что без сервера приложений клиент с базой данных работать не сможет. Тут, я, конечно, немного утрирую. Однако я не понимаю, почему клиент не должен работать с «объектной моделью», как Вы пишите. Проблемы здесь зарыты глубже. И затык не в мощности клиентского компьютера, а в конкретной реализации технологии доступа к данным со стороны «толстого» и «тонкого» клиентов к серверу приложений. У «толстого» клиента она, скажем так, менее оптимальна, чем у «тонкого». Именно поэтому фирма «1С» рекомендует переходить на «тонких» клиентов. К сожалению, за это приходится расплачиваться потерей некоторых приятных возможностей толстого клиента.

The Dim!Кроме того, в своих рассуждениях, вы не различаете где речь идет о реализации бизнеслогики, а где речь идет о хранении данных.
Ну, это Вам так кажется. Наоборот, я говорю о существовании множества различных способов распределения бизнес логики между клиентом и сервером.

The Dim!В 1С, бизнес логика, частично выполняется на клиенте а частично на сервере. SQL сервер, в 1С, выступает исключительно и только как хранилище данных. Ни одна строчка кода бизнеслогики 1С не может быть выполнена на строне сервера баз данных. А вы, в своих рассуждения (ссылаясь на тех.лит), рассуждаете допуская это.
Конечно, это не полноценная статья и сумбурный стиль изложения вполне может быть. Но и я тоже утверждал раннее, что «1С» все равно с чем работать, то ли с MS SQL Server 2000, то ли с MS SQL Server 2014. Она и в «семерке» использовала SQL Server только как хранилище данных и продолжила эту практику в «восьмерке». Платой за такой подход является необходимость покупать дорогое «железо». Просто я часто о технологии клиент-сервер говорю вообще, а не только исключительно в рамках решения «1С».

The Dim!1С, позволяет, масштабировать решение, средствами самой же 1С. Другое дело, насколько, люди занимающиеся внедрением понимаю эту самую 1С.
По хорошему, сама фирма «1С» должна предлагать подробные типовые схемы проектов внедрения. По сути, любой фирме, собирающейся внедрять 1С, особенно «восьмерку», нужен реальный проект внедрения, выполненный специалистами, с учетом конкретной специфики предприятия, где бы была утверждена как технология работы, так ее смета. Кратко это можно было бы назвать «Технологической сметой» внедрения конкретного решения на базе 1С8х. В идеале «технологическую смету внедрения 1С» должна составлять одна фирма, а внедрять должна совершенно другая фирма. А сметы должны быть не с потолка, а утвержденные на уровне министерств и ведомств. А поскольку эта бюрократия пока не работает, что все фирмы составляют подобные проекты на ходу и по принципу «как первый раз замужем». Про «откаты» и «отпилы» я вообще молчу. А процесс внедрения 1С часто плохо понимают даже те, кто пишет книжки с рекомендациями по этому внедрению. Легко написать, например, «проведите предпроектное обследование своего предприятия» и т.п. А если поискать примеры в Интернете такого обследования, то сразу видно, что делалось не слишком профессионально. И так по всем пунктам подобных рекомендаций.

The Dim!Миллион проводок... это такое же абстрактное понятие как сферический конь в вакууме. Это взято из интервью руководителя проекта внедрения 1С на Камазе (см. ссылки выше), для них это реальное понятие. А на ветке форума, где обсуждается ERP, любят говорить о «тысяче проводок в минуту».

The Dim!Назначение тонкого клиента сводится к вынесению большей части бизнеслогики на сторону сервера приложений (но не сервера БД). Это не реклама и не коммерция. Это, как раз один из инструментов, который позволяет масштабировать решение.
А зачем ее выносить? Оставьте, всю бизнес логику в толстом клиенте, благо, клиентские компьютера сейчас достаточно мощные. Но толстые клиенты плохо масштабируются, нужно стороннее решение вроде терминальных серверов. А почему? А потому, что толстый клиент плохо работает с сетью (тонкий получше). Поэтому, я считаю, что тонкие клиенты подобны терминальным клиентам, а сервера приложений (точнее, рабочие сервера кластера серверов) – терминальным серверам. Иначе говоря, фирма «1С» реализовала собственное подобие терминала (для локальной сети). Зачем? Понятно, что за терминальные сервера Мелкософта она бабла не получит, а за свои собственные сервера приложений аж бегом.

The Dim!Применение терминальных серверов обусловлено иными факторами.
Какими?

The Dim!Для того, что бы это понять, нужно понять архитектуру работы всей платформы 1С:Предприятие, как саму по себе, так и в увязке с серверами баз данных. Вы вырвали сервер приложения их контекста и рассматриваете его как нечто абстрактное. Ну так и результаты будут... :)
Вы можете посоветовать источники полноценной информации? Замечу, что большинство популярных книг по 1С плюс документация у меня уже имеется. Поэтому простые схемки «черных ящиков» без подробных технических нюансов не катят.

The Dim!Пример не понимая вами того, что сами пишите. Да, может быть и сервер баз данных. Потому что, сервер баз данных, может не иметь должного обслуживания. Фрагментация, не верная статистика(как следствие, ядро СУБД будет строить не корректный план запроса), не корректная настройка прироста файла данных и файла лога. Не корректный выбор места размещения файла БД и файла лога... не корректное размещение tempdb... и т.д. и т.п. Если вы этого не видели, и не читали это... ну так расширяйте кругозор :) Да и кто сказал, что платформа, на которой развернут сервер баз данных удовлетворяет требованиям?
Понимаете, проблемы на стороне сервера БД, это как говорят студенты: «не проблемы, это всего лишь задачи». Работа серверов БД достаточна прозрачна в техническом плане, существующей информации более, чем достаточно, чего не скажешь про сервер приложений 1С, о котором информации как воды в «скупой мужской слезе». Дайте мне спецификацию работы кластера серверов, ту которая «для служебного пользования» и мне больше от 1С ничего не надо.

The Dim!Приведенный вами пример камаза никак не характеризует 1С (или любого другого вендора). Приведенный пример говорит о том, что не была проработана архитектура информационной системы в целом. Ведь кто-то же, говорил куда ставить кластер, куда ставить сервер баз данных. Кто-то выбирал аппаратную платформу... кто-то организовывал коммуникацию между всем этим.
Чем эти люди руководствовались? А виновным назначили 1С.
Не думаю, что Вы правильно интерпретируете сказанное. Камаз постоянно обслуживает внедренческая фирма «Интелком» (75 человек которых безвылазно сидят там) плюс прямой договор директора Камаза с Борисом Нуралиевым плюс спецкурс фирмы 1С по проблемным местам на уровне кода платформы и т.д. Вы думаете, что собственными силами (10 программистов «1С») Камаз мог бы составить квалифицированный проект Технологической сметы внедрения? Боюсь, что подобной сметы у них нет до сих пор. А попробуйте без сметы утвержденного проекта построить хотя бы дом. Т.е. производственные работы без сметы и технического проекта делать нельзя, а «1С» внедрять можно. «Вина» «1С» только в том, что она «зажимает» ключевую информацию. Если бы они опубликовали реальную технологическую смету (хотя бы постфактумную) своего внедрения на Камазе, пусть без излишних служебных подробностей, то всем было бы на что ориентироваться при «проработке архитектуры информационной системы в целом».

ХитроглазыйВы пишите как администратор бд, который абсолютно не имеет понятия (да ему и все равно), что происход вне его СУБД. Если мы говорим об Архитектуре ПО или Архитектуры системы, то утверждать такое просто невежественно.
Позвольте с Вами не согласиться! Для сервера БД клиентом является сервер приложений, а не собственно клиент 1С. Давайте объединим клиентов и кластер приложений в одно логическое понятие и получаем типичную двухзвенку. Другое дело, что лично Вам такое объединение может и не понравится, тогда просто напишите, не согласен мол с таким произволом, потому, что. . . Иначе это будет не слишком конструктивно.

ХитроглазыйEmeryЛично я трехзвенку воспринимаю как двухзвенку, со сложным клиентом, состоящих из двух компонентов.
Давайте Ваши личные проблемы восприятия мы оставим за рамками этой ветки.
Вообще-то дискуссионный форум, а не экзамен по ЕГЭ. Не согласны, напишите, почему или не отвечайте.

ХитроглазыйОбычно ищут решения, а не проблемы. В любом случае демагогию, а так же вопросы архитектуры "вообще, а не конкретно для 1С" тоже лучше вынести за рамки.
Сначала все-таки определяются с проблемами, а уже потом со способами их решения. Разве не так? Я лично на демагогию не реагирую и Вам советую.

ХитроглазыйEmeryОднако я не понимаю, почему клиент не должен работать с «объектной моделью», как Вы пишите.
Я такого не писал. Работайте в толстом клиенте.
А я и не говорил, что Вы писали, имелись в виду причины технических различий.

ХитроглазыйС учетом поправок на рабочие сервера и, если у Вас получится решить проблему с выбором рабочего сервера, система работать будет. Все что касается вопросов производительности, количества клиентов и прочих нюансов - тут Вам ни одно теоретическое изыскание ответов не даст. Все слишком индивидуально: какая конфигурация (1с, серверов, сети, какая ОС, СУБД), какие клиенты, какие операции и с какой частотой над какими данными они выполняют. Без проведения нагрузочного тестирования все ответы будут пальцем в небо.
Все правильно, но меня интересовало не это. Кое-что я понял из общего обсуждения, так что конструктивно спорить никогда не вредно. Кое-что запланировал себе для самостоятельной работы.

Хитроглазыйкурс
http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=199
Недавно вышла книга (правда сам ее в руках не держал, но, судя по оглавлению, содержит теор. часть курса)
http://v8.1c.ru/metod/books/book.jsp?id=452
Не совсем то, хотя ознакомиться будет не вредно. На Камазе был другой курс, касающийся вопросов низкоуровнего кодирования платформы.

The Dim!А почему, по вашему, 1С должна это делать?
Что значит "типовую" схему внедрения (типовую, это значит универсальную) ?
Она это делать не должна, но я бы на их месте сделал бы. Просто в силу общепризнанной технологии производственных работ. Любое производство подразумевает проектирование, формирование смет, согласование, утверждение и только потом реализацию. Ну, если мы не считаем процесс внедрения «1С» производственным процессом, тогда «чертежи», проекты, сметы, подписи и т.п. нам не нужны. А то будет как в анекдоте из жизни. Один чувак принес в цех чертежы на швабру, все путем, допуски, посадки, стандарты проектировании и т.п. были соблюдены на 100%. Можете представить себе как посмотрели рабочие на этого интеллигента. По-видимому, я тоже как тот интеллигент ломлюсь со своими чертежами швабры :) .

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

The Dim!Если, в типовой схеме проекта внедрения, 1С (или кто-то третий) выдвинет требование о наличии строго определенной конфигурации серверного оборудования... ну например, только сервера IBM и только сетевое оборудование от циски...
Что делать предприятию, если у него есть сервера, но не IBM, а от HP, а сетевое оборудование D-Link ?
Или, наличие MS SQL Server 2025, а у предприятия только 2005... и нужно, что бы был Windows Server Enterprice... в у нас стандрат...
Как быть предприятию?
В компьютерном мире решаются и более сложные задачи. Например, возьмем бесплатную программу Blender для создания 3d-анимации. На ней такие чудеса делаются, что диву даешься. А принцип работы очень прост, все сводиться с примитивам, на базе которых искусственно формируется даже такая экзотика как живой огонь, изменяющая морская рябь, движущийся туман и люди, похожие на настоящих и много чего еще.

Любой проект перечисляет регламентные работы. Любая такая работа разбивается на элементарные действия. А все эти действия имеют расценки и прочие параметры в стандартизированных ведомственных сборниках. Поэтому и здесь делим все возможные работы на элементарные и их уже обсчитываем. Из справочников выбираем оборудование и средние цены на определенный период (разногласия по факту потом регулируются отдельно стандартным образом). Подробный шаблон хорош тем, что позволяет не пропустить какое-либо обязательное действие. Причем сметы могут иметь дополнительные приложения и даже быть полностью пересчитаны, если реальность поменялась. Как правило, сметы на каждый проект составляются индивидуально ибо 100%-ного сходства никогда нет. Но вот соответствовать шаблону они могут на много процентов.

The Dim!Поэтому типовые схемы не жизнеспособны.
В производстве все проекты строятся на базе типовых, возьмите хоть запуски космических кораблей на космодроме. Однако конкретные сметы и их проекты всегда индивидуальны. И не для кого это не является проблемой. Просто там всегда есть условный «Хозяин», а «1С» таким «Хозяином» быть не хочет, а заставить некому – «революционный демократизм», блин.

ХитроглазыйEmeryНе совсем то, хотя ознакомиться будет не вредно.
Я даже больше скажу, ознакомление обязательно, особенно в Вашем случае.
В моем списке для ближайшего изучения много источников. Если времени хватит, то изучу и Ваши.

ХитроглазыйEmeryНа Камазе был другой курс, касающийся вопросов низкоуровнего кодирования платформы.
Никакого курса низукоровнего кодирования платформы нет. Не пытайтесь придумывать на пустом месте.
В интервью во фразе " оптимизировать систему на уровне кода " речь идет о исключительно о коде прикладного решения (конфигурации). Ссылку на нужный вам курс я привел выше.
Вот буквальная цитата:

Рустем_АвхадиевА проблема сама по себе была, как говорят программисты, низкоуровневая: мы не знали “внутренностей” системы, каким образом она обрабатывает запросы, как записывает данные. Но прошли специальный курс обучения и успешно оптимизировали систему на уровне кода (формирование запросов, блокировка пользователей при совместном обращении к одним данным и так далее), решив таким образом задачу повышения ее производительности.
Обратим внимание на слова: « низкоуровневая » и «прошли специальный курс обучения».

Т.е. речь идет о том, что после того, как спецы узнали « внутренности » платформы «1С» они смогли, с учетом этой информации(!) «успешно оптимизировать систему на уровне кода» (понятно, что уже прикладного, т.е. на языке «1С»).

Возможно у Вас другая версия, но вряд ли более обоснованная.

ХитроглазыйНу а теперь посмотрите на программу треннинга "Повышение производительности и масштабируемости систем" по ссылке, что я Вам дал, особенно на второй и третий день, и перестаньте строить догадки и теории заговора.
Откровенно говоря, меня эта программа не впечатляет. Да, кое-какая интересная информация там будет, но не думаю, что принципиально новая, которую невозможно получить косвенным путем из других источников. Этот тренинг пусть они проводят для кодеров типовых конфигураций. Пусть, фирма «1С» даст гарантии, что такая-то конфигурация, допустим, при 100 интенсивно работающих пользователях, дает приемлемую производительность на таком и таком-то «железе» и ПО за такую и такую-то стоимость. Или они предлагают нам (сотрудникам предприятий, где внедрена или внедряется «1С») самим оптимизировать их код типовой? Когда я пишу собственные конфигурации, мне их советы постольку-поскольку, все равно буду делать по своему. А так, у меня достаточно хорошей литературы и без этого.