Лохматый баян, но тем не менее.
Если сравнивать управляемое приложение 1с: толстый и тонкий клиент по локальной сети без веб-сервера.

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

В тонком есть очевидное ограничение с точки зрения программиста 1с. Например, на клиенте нельзя использовать таблицу значений.
За счет этого, будет меньшая нагрузка на клиентскую машину, т.к. программисту уже сложнее будет создавать большие коллекции на клиенте. Есть еще ограничения?

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

Или же такими вопросами не нужно задаваться, и фирма 1с оставила толстый клиент и таблицы значений для обратной совместимости с криворукими программистами?

(0) Тут более важно другое - управляемое или обычное приложение. Если приложение обычное - тонкого клиента не существует. Если управляемое - толстый клиент сделан для переходного периода.
Разумеется, тонкий клиент легче, потому что в нем не реализовано куча всего что есть в толстом.

(1) > Тут более важно другое - управляемое или обычное приложение
С этим вопроса нет

> не реализовано куча всего что есть в толстом
Что именно?

(2) Работа с объектами на клиенте. Хотя тут непонятно как тогда работает тонкий клиент-файловая поставка

И почему нельзя ТЗ на клиенте использовать. Я пользовался - проблем нет. Проблемы с передачей ТЗ между сервером и клиентом которое обычно обходится после преобразования ТЗ в массив+соответсвие

(4) ???

(0) (1) Тут еще важно третье — файловая или клиент-серверная база. Если файловая — все выполняется на клиенте, даже серверная часть.

интересно рассмотреть, конечно, только клиент-серверный вариант

(4) в тонком клиенте нельзя тз использовать

(2) >> не реализовано куча всего что есть в толстом
>Что именно?

Открываешь СП и смотришь объекты и их методы, раздел "Доступность".

Например, недоступны менеджеры прикладных объектов, методы типа Выбрать..., наборы записей — в общем все, что лезет в базу.

(9) менеджеры - ок
выбрать, наборы записей - это уже производные от менеджеров

> Открываешь СП и смотришь объекты
Шерстить весь СП нет желания, поэтому спрашиваю

(10)
В частности на тонком клиенте недоступны все прикладные типы данных. Вместо этого тонкий клиент оперирует ограниченным набором типов встроенного языка, предназначенным лишь для отображения и изменения данных в памяти. Вся работа с базой данных, объектными данными, исполнение запросов – выполняется на стороне сервера. Тонкий клиент только получает готовые данные, подготовленные для отображения.
(с) http://v8.1c.ru/overview/Term_000000124.htm

(10) >Шерстить весь СП нет желания, поэтому спрашиваю

Круто. Предлагаешь нам это сделать вместо тебя и где-то через полгода ответить?

(12) нет, этого не предлагаю

В общем, пока делаю вывод, что тонкий клиент облегчен только за счёт ограничений. И, к примеру, запускать типовую в локалке на тонком или толстом -  разницы нет, Ут 11 например.

(14) Разница есть. На тонком через веб-сервер будет работать быстрее.

Просто нужно хорошо понимать так называемую 3-tier модель. Есть сервер базы данных, сервер приложения и клиентское приложение. Клиентское приложение - это только компонент представления. В известной степени тут работает аналогия с  терминальным клиентом - ловим клавиши, клики мышой, передаем их на сервер, с него картинки принимаем и показываем. Вот как бы надо исходить из того, что ничего особо сложнее этого на клиенте делать не полагается. "Тонкость" - в простоте вычислений на клиенте и малом трафике между клиентом и сервером, что позволяет работать на дерьмоканалах.

(15) ну в (0) я спрашивал про вариант без веб-сервера

(15) что именно будет быстрее работать и почему?

(18)Никакой разницы если УТ11 работает на sql или в терминале. Если это расшаренная файловая и там пользователей больше двух, то разницу поймешь через 20 минут работы.

(18) В файловом варианте кроме тонкого клиента запускается "сервер (файловый вариант)" который собственно и исполняет роль сервера 1с предприятия. Это можно увидеть в "отладка"-"подключение" при запущенном отладчике Ну а так как это происходит на локальном компе, увеличения производительности не будет.

(19) (20) коллеги, см ветку внимательнее, в частности (7)

(21) допустим запрос в цикле так же плохо, как НайтиПоНомеру на клиенте в толстом. Что результатзапроса обрабатывается в НаСервере, все поля аккуратно выбираются в запросе, даже Представление, никаких УстановитьПометкуУдаления. И вся конфигурация написана хорошо, идеально для клиент-сервер, ни одного скрытого вызова сервера. Что сервер и клиент мощные с избытком, сеть широченная.
Тогда пофиг.

(22) это ответ на какой вопрос?

(15) Все таки, ты имел ввиду, что в клиент-серверном режиме с веб-сервером будет быстрее?

(24) Тут много влияющих факторов. Но чаще всего - да, будет быстрее.

(25) почему, в общем случае?

(26) А ХЗ, тесты и замеры так показали.

(26) это надо десятки тысяч экспериментов провести, на разных данных и разных компах, потом вывести средний процент. Тогда будет ясно, что быстрее. А так как вы хотите, кто-то запустил один раз задание, на глазок замерил, оно выполнилось быстрее. Так не делается, зачем такие выводы скоропалительные?,

Вообще, сама методология клиент-серверного взаимодействия подразумевает ЧЕТКОЕ РАЗДЕЛЕНИЕ сервера и клиента. Это в 1С код сервера и код клиента можно разместить в одном модуле с применением директив. А так-то обычно с клиента нет никакого доступа к серверному коду - только возможность выполнять запросы и получать их результаты. (В 1С это возможно, и неграмотным использованием часто все преимущества клиент-сервера сводятся на нет.)

Поэтому на нормальном клиенте остается возможность выполнения только простейших действий вроде сложения/умножения, а для этого много ресурсов не требуется. Хотя, при неграмотном использовании можно и клиента повесить.

На этих выходных тестировали в течение 11 часов собственный тонкий клиент для 1С:ITIL. За это время создано больше 20000 документов через браузер в 1000 параллельно работающий пользовательских сеансах. В среднем один новый документ записывался раз в две секунды. Процессор на сервере при этом показывал в среднем 40-50% загрузки, на клиенте - 10-15%.

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

>через браузер в 1000 параллельно работающий пользовательских сеансах.

Это как, 1000 виртуалок, 1000 вкладок или как?

>на клиенте - 10-15%

Как померили?

(28) я написал, что в общем случае
если хотите - теоретически, с обоснованиями

+ (28) т.к. человек написал, что будет быстрее - отсюда у меня вопрос - как он определил

(29) это все интересно, но совсем оффтоп

в действительности ничего не мешает транслировать серверный код напрямую в базу.
это позволит многократно сократить время отдачи данных и СКОМПИЛИРОВАТЬ код

(31) Записали запросы одного сеанса в лог, на его основе сделали сценарий действий одного пользователя, размножились тысячекратно и нагрузили этими запросами тестовую базу. Генерили запросы и меняли время их исполнения самописной подсистемой нагрузочное тестирования.

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

(37) > Меньше ресурсов - это заслуга не только архитектуры тонкого клиента, но и того, насколько грамотно написан код
С этим согласен но, для работы в тонком клиенте просто не получится написать код, который работает с объектами и т.п. К ним относятся все типовые, как я понимаю. В частности УТ 11. Отсюда я сделал вывод в (14), что запускать типовую в локалке (tcp/ip) на тонком или толстом - разницы нет по производительности.

(36) > Записали запросы одного сеанса в лог
Это вашей подсистемой делали?

(39) Да, своей.

Менее требователен? ХА-ХА.
Это теперь, когда для запуска бухии подавай 4ГБ памяти?

Когда открытие формы вешает Core i5 на несколько секунд?

(41) Так у них там сейчас тонкий клиент такой не тонкий, что ничего удивительного в этом нет. Миллионы строк, и все это грузится в оперативку. Хорошо, хоть асинхронные вызовы начали активно юзать.

(43) в однопотоке асинхронные вызовы не спасают

ну или если только при работе с внешними ресурсами

(44) Ну хотя бы интерфейс не блокируется, и за то спасибо.

(36) То есть это совсем не "через браузер".

Еще поясни, пожалуйста, вы записывали и воспроизводили именно запросы к базе, то есть INSERT-SELECT-UPDATE? Или все-таки вызовы серверных методов, создающих и записывающих документы? Если первое, то это получается настолько синтетический тест, что его результаты никак не характеризуют работу тонкого клиента. Это получается тестирование скуля. И судя по результату "один новый документ записывался раз в две секунды" скуль ваш работал фигово.

(47) Скуль, инсерт и прямые запросы к базе тут вообще не причем. Тонкий клиент общается с базой через http-сервисы. Логировали http-запросы и на их основе сформировали сценарий.

(41) Слово "тонкий" по своему собственному значению немного устарело (требования к памяти и всё такое). Но его можно интерпретировать и по-другому, например, в рамках всяких "тонких материй" типа астрального тела, которое переживает выход (гибель) из материального тела. Тонкий клиент легко переживает разрыв коннекта с сервером, чего толстый клиент не переживает (закрывается с ошибкой).

(49) У многих тонких этот разрыв происходит вообще после каждого запроса при работе через http-протокол. То есть, между двумя запросами он может запросто переключиться на резервный сервер и пользователь этого даже не заметит.