Выложил БД на шару, сетка сотка, но в общем и целом скорость доступа, работы и общее ощущение взаимодействия с базой нормальная. Довольно часто можно услышать рекомендации относительно публикации файловой базы на веб-сервер, Апач/IIS и хотелось бы узнать мнение спецов, есть ли смысл заморачиваться, если приемлемо всё на данный момент? Кроме вероятности повышения производительности работы с базой (сжатие), будут ли некие иные аспекты оказывающие положительное влияние на работу с базой? Типа сохранения целостности БД, обеспечения более аккуратного доступа к данным и тому подобное? Или кинул на "шару", работает и пускай дальше работает и незачем плодить сущности и усложнять архитектуру?

Конфы ОФ не умеют через веб-сервер.
В случае УФ конф работа через веб-сервер (файловой) намного лучше.
Там банально разделение и "серверная" часть с запросами выполняется на той машине где база лежит.

Но если у тебя база лежит не на локальном ssd (там же где и веб-сервер) а на некой отдельной шаре - однофуйственно

И да

Смотри на 4 гигах оперативки файловая по шаре конфа тупо загнется
Если же базу и веб-сервер засунуть на комп с ssd и с хотя бы 8 гиг рам (лучше от 16 с учетом если не выделенный а еще юзер работает) то исполнение 1С поделится на клиентскую часть (4 гига на одного юзера) и "серверную" (8 гиг на нескоко юзеров)

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

(3) Машинка хорошая, 32 гига оперативки, проц. i5, не совсем из свежих, сейчас не помню точно, но 6, 7 поколение вроде, диск SSD.

Меня собственно перспектива "падения" Веб-Сервера беспокоит, все-таки SMB "шара" более простой и стабильный механизм, сервис, если я правильно понимаю, ну, а Веб-Сервер уже более сложная сущность, неожиданное "падение" которого можно лишить доступа пользователей к БД.
У клиентов ведь тонкие клиенты надо будет настраивать на доступ по-веб протоколу, если публиковать базу на веб-сервер, верно? Что будет, если Веб-Сервер упадет, клиент в базу не попадает тогда, так ведь?

Кстати, а как будет происходить выдача лицензий при публикации бд на веб-сервере? Веб-сервер + Файловая 1С умеет выдавать лицензии сама, как "настоящий" 1С Сервер Приложений? Или у клиентов надо будет локальные ставить? Тонкие клиенты работать не будут,

(4) С указания конфигурация надо было начинать, многие ККТ в вебе глючат, без ККТ ВЕБ-сервер предпочтительнее.

Файл-серверный доступ к базе данных 1с8 - зло!

(6)"перспектива "падения" Веб-Сервера беспокоит, все-таки SMB "шара" более простой и стабильный механизм,"
Говорить о "стабильности" в случае файловых блокировок по SMB-протоколу - это шутка такая? Для SMB есть своё применение - свалка документов. Для СУБД он категорически неприемлем. Даже netware в своё время работала на порядок лучше с сетевыми базами, чем SMB.

(7)>как будет происходить выдача лицензий при публикации бд на веб-сервере? Веб-сервер + Файловая 1С умеет выдавать лицензии сама, как "настоящий" 1С Сервер Приложений?
лицензии может выдавать веб-сервер, но надо учитывать, что при этом лицензия выдаётся на каждый сеанс/запуск, т.е. если на одном и том же ПК будет запущены две базы, то будет израсходовано и две лицензии.
если на клиентском ПК для работы будет использоваться тонкий клиент 1С, а не веб-клиент, то лицензию можно активировать и на клиентской машине и на ней можно будет запускать сколько в одно баз используя только одну лицензию, но придется побегать при активации

netware умышлено была заточена на многопользовательский режим доступа чтение-запись

Вообще, в случае использования базы у ТС наблюдается очень мало-нагруженный режим использования базы. Например, второго пользователя нет совсем или даже если он включается в систему, то ничего не делает и система его сессию успевает отключать или что-то еще к ней применять, после чего основной сеанс работает более-менее нормально и не вызывает претензий у основного пользователя СУБД

(7) А лицензии у тебя сейчас как раздаются? Вот пусть так и остается. :)
Что ты сейчас запускаешь толстого клиента, что потом будешь запускать тонкого клиента - однофуйственно, как тут выше сказали :)
Зато всегда можешь вернуться с тонкого на толстый или даже комбинированно - одну базу тонким клиентом, другую базу толстым. Вдруг у тебя другая база появится, даже не по сети, а локально у какого-нибудь юзера.

Менять раздачу лицензий на раздачу через веб-сервер в твоем случае имеет смысл только если ты планируешь ходить в базу не тонким клиентом, а веб-клиентом.

(11) "если на клиентском ПК для работы будет использоваться тонкий клиент 1С, а не веб-клиент, то лицензию можно активировать и на клиентской машине и на ней можно будет запускать сколько в одно баз используя только одну лицензию, но придется побегать при активации"
Не обязательно бегать, тонкий клиент нормально аппаратные сетевые лицензии через nethasp получает.

(15) +100500
Учитывая, что у автора УЖЕ все раздается через шару, т.е у него уже стоят толстые клиенты на каждой машине и, соответственно лицензии уже установлены на каждой машине.
При переходе на тонкого клиента ему вообще ничего делать в части лицензий не надо.

(8) >многие ККТ в вебе глючат

Очень смешно, тонкий клиент 1С же причем тут ККТ в вебе.

(8) ККТ на некоторых клиентах используются, да. Будут глючить и при использовании тонкого клиента ? А какого плана глюки и почему так получается, если сталкивались, можно чуть подробнее, победить не получается в результате, только на файловый доступ настраивать на "шару", если ККТ ?

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

(15) >тонкий клиент нормально аппаратные сетевые лицензии через nethasp получает.

получает, но если бы у ТС был аппаратный ключ, то не думаю, что он этот вопрос вообще бы стал поднимать

(6) все как раз наоборот. Веб-сервер - это один из самых отлаженных ввиду массовости сетевых механизмов. SMB специфическое и довольно дырявое поделие, страдающее еучей болячек, которое применяют в основном эникейщики ввиду простоты работы с ним.

(17) Вот я тоже не понял и обратился с дополнительным вопросом, чтобы разобраться. Клиенты ведь будут не через браузер работать с файловым сервером, а через ТОНКИЙ клиент 1С, в котором доступ к базе будет прописан через использования веб-сервера http://..... Может в таком режиме, когда к Веб-Серверу доступ через Тонкий, то 1С не отдает некие файлы из БПО, для оборудования или не эффективно ими управляется? Как вариант, не знаю, просто строю догадки. При "взрослой" клиент-серверной архитектуре, 1С СерверПриложений +СУБД таких проблем при работе с ККТ не возникало, а Веб-Сервер не поднимал.

(16) Да, всё верно, лицензии клиентские на машинах пользователей установлены, но планируется получение многопользовательской лицензии на 5-10 пользователей, поскольку будут еще удаленные пользователи подключаться к базе. Поэтому хотелось понять как организовывается раздача лицензий с файловой 1с+ВебСервер. Просто менеджер лицензий надо будет поставить, NetHasp, ?
Или у Веб-Сервера есть свой механизм раздачи сетевых лицензий?
Какой вид многопользовательского ключа (5-10) лучше будет выбрать, аппаратный ? Программные не рекомендуются  при таком раскладе?

(18) Глюков работы с ККТ в тонком клиенте не замечал.

(14)///Менять раздачу лицензий на раздачу через веб-сервер в твоем случае имеет смысл только если ты планируешь ходить в базу не тонким клиентом, а веб-клиентом.

Ходить планируется только "тонкими", но мне так представляется, что возможность "сходить" через браузер на базу, пускай изредка, для общей аналитики, "одним глазом глянуть" и буквально только одному или двум пользователям, была бы востребована в общем-то.

Поэтому вопрос; что подразумевается под термином "поменять раздачу лицензий через веб-сервер" в контексте работы связки 1С-Файловая+ВебСервер ? Просто поставить менеджер раздачи лицензий НетХасп и раздавать с него многопользовательские ключи? Или в файловой 1С есть тоже механизм раздачи лицензий, как в 1с Сервере Приложений, где можно поставить реальную "птичку", чтобы 1С сервер раздавал лицензии, без помощи всяких НетХасп и прочих.

(25) боже, как все смешалось в доме Облонских..
Нетхасп работает  с конкретной железякой. Стороннего разработчика, между прочим.
Понимаешь, вот есть МФУ,к примеру НР. К нему прилагаются драйвера и прочее ПО, сканировать там, центр управления и прочее.
Но это железяка НР, и, к примеру, с куосерой или  бразерсом в общем случае работать не будет. Так это, заметь, две железяки.

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

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

(26) как я был в одно время зол на 1С когда путем тестов выяснил что аппаратный ключик = тормоза в 1С относительно программного

(26) + нарена=нахрена :)

Дальше. Программная лицензия, установленная локально на компе(рабочей станции) позволяет запускать сколько угодно баз на этом компе.

Программная лицензия, получаемая компом (рабочей станцией) от сервера, тратится по одной на каждый сеанс. Две базы откроешь- две лицензии сожрет, три базы - три лицензии. Даже одну базу два раза откроешь - все равно две лицензии отожрет.
Поэтому убирать программные лицензии со станций юзеров и переводить их все на сервер - хм.. не вижу смысла. В упор не вижу. Если (ЕСЛИ) ты будешь работать тонким клиентом. Только сам себе хуже сделаешь, тем более уже все лицензии установлены и работают.

Но одновременно ты планируешь работать удаленно через веб-клиент. Вот тут для таких клиентов (удаленных и веб) ЧАСТЬ НОВЫХ программных приобретаемых лицензий можно раздать и через web-сервер.

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



(27) локально- хм.. тормоза есть, но незаметно. А по сети - тормоза снижаются, если жестко прописывать адрес ключа и запрещать бродаксат. Хотя все равно медленнее, да, ты прав.
Ну дык - обратиться куда-то по сети к стороннему поставщику, тот пока прочитает железку в порту, получить ответ от LM - по-любому какое-то время нужно.

(26) Это всё понятно ;), Я затронул NetHasp поскольку многопользовательский ключ на 5 или 10 пользователей планируется заказать аппаратный, а так понятно дело что для программных лицензий аппаратный менеджер лицензий не нужен.
Но мой вопрос был в другом, каким механизмом будет происходить раздача лицензий на 1С файловом сервере с опубликованной на ВебСервере базой ? Вы просто выше сказали "менять раздачу лицензий", где это меняется?
Как ВебСервер раздает аппаратные или программные ключи? Сам по себе или утилита нужна будет?

(28) >локально- хм.. тормоза есть, но незаметно.

С какой то версии вроде с 8.3.17 локальные тормоза дико возросли, у меня тест Гилева в два раза меньше попугаев выдавал

(29) Если у вас тонкие клиента 1С (не веб-клиенты) то глубоко пофиг
Тонкий клиент умеет лицензию получать от менеджера или локальную

(31)+ И да особенности лицензирования что лучше не от сервера лицензию ибо они на каждый сеанс а не на комп/юзера

(31) Программные лицензии ? От какого менеджера? Вот я допустим заказал 10 программных лицензий, многопользовательских, сетевых. Как они будут раздаваться по сети пользователям в связке 1С Файловая+ВебСервер ? Есть какой-то программный менеджер, встроенный в 1С ?

(33) аппаратную usb от менеджера подразумевал

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

(35) не совсем так, сначала последний использованный ключ/лицензия пытается получить и если ее нет или первый запуск то твой алгоритм

Покупать железный ключ ХАСП и раздавать его для тонких клиентов через веб-сервер - глупость.
Через менеджер лицензий его можно раздавать в режиме "на компьютер" .
А через веб-сервер - только в режиме "на сеанс." Напуркуа так делать, я хз?

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

(29) в случае с аппаратным ключом, который установлен на сервере, тонкий клиент может получить лицензию как от HASP LM, так и от веб-сервера,
клиент будет сначала пытаться получить лицензию от HASP LM, а потом от веб-сервера,
какой-то настройки, как в кластере, которая бы позволяла вкл/выкл раздачу лицензий сервером в файловом варианте нет

(35) теперь понятно, спасибо за подробное разъяснение! Один вопрос; а в случае использования аппаратного ключа на 1с файловом сервере+ВебСервер, всё тоже самое или только программный так раздается, а аппаратный только через ХаспНет ?

(39) Понял, спасибо! То есть наличие ВебСервера и публикация БД на этом ВебСервере автоматизируют выдачу сетевых, многопользовательских лицензий, аппаратных? И можно обойтись без ХаспLM ?

Еще один вопрос ко всем достопочтенным участники обсуждения!

Если прогнозируется увеличение количества пользователей, приблизительно говорят, что к весне может уже около 10 быть активным пользователей, правда с удаленными вместе, по всем известным причинам повальных удаленок, то есть ли философский и логический смысл задумываться уже сейчас о клиент-серверной архитектуре ? Существует ли лицензия на МиниСервер с более чем 5-ю пользователями, 10 к примеру?
Можно было бы сразу ставить 1С+МSSQL EXPRESS бесплатный и с веб сервером уже не заморачиваться? Или это неправильная идея ?

(42) 10 активных юзеров можно и на файловой опубликованной через веб-сервер держать.
Если будут фризы (там по сути однопользовательский режим доступа веб-сервера по очереди) то через несколько апачей запущенных на разных портах можно разрулить.

(42) Сервер мини на 5 подключений хрень, полезна только в случае регламентных тяжелых

(0) шифровальщик расставит все точки над i

(44)  у мини сервера ограничения в производительности ? Или только на количество пользователей ?
Обычный сервер, безразмерный не купят, ценник слишком страшный, а на 5 Ползователей наверное и смысла нет. Тогда выходит надо обходится файловой с веб-сервером.

(46) ограничение на кол-во юзеров
но настоящая серверная база со всеми плюшками и недостатками
плюшки что регламентные на сервере выполняются а недостатки что тормозит на юзера относительно файловой

(47) Понял, спасибо!
А что за тормоза "на юзера" на серверной относительно файловой? Работал на клиент-серверной с различными конфигами, особых тормозов не наблюдал, если сравнивать с запуском и работой с файловой, то не знаю, на мой взгляд более шустро всё происходило, сжатый режим. Из-за чего тормоза могут возникнуть у серверной и в чем файловая может выигрывать у нее в плане производительности ?

(48) не-не sql версия всегда тормозней файловой на том же железе
но ее плюс что там где загнется файловая на много юзеров/запросов то серверная sql будет пусть и медленно по тащить

(49)+ публикация файловой базы на веб-сервере и работа в УФ через него это такая промежуточная штука
скорость почти как у файловой локальной пока юзеров не сильно много

(49)+ тормозней в однопльзовательском режиме

(49) Понял, не спорю, не компетентен в этом вопросе, могу только на субъективные ощущениях
опираться, которые вполне могут быть ложными  ;).
А с какого количества пользователей, примерно, начнет загибаться Файловая+ВебСервер. ? Ну, приблизительно, если опираться на практический опыт работы. На этот счёт разные данные, в основном "паспортные", "на бумаге", принято называть цифры до 7-10 пользователей для Файловой, дальше идут рекомендации перелезать уже на SQLьную. Хотя на некоторых ресурсах можно встретить и рекомендации о переходе на SQL уже начиная с 5-ти пользователей, в оправдание приводят выпуск от самой 1С мини-сервера именно на такое количество пользователей.

(52) все сильно зависит от колва бабла у клиента ))
на практике до 20 юзеров можно на файловой на типовых, на самописках до 100

(53)+ появление шустрых ssd и рост частот процов до 5ГГц сильно расширили возможности файловой
Но если у клиента дешманский (пусть и дофигаядерный) проц частотой ~2ГГц то тут файловая (особенно если крутой дорогой но дико устаревший raid на sas) будет загибаться даже на 5 юзерах и выход только sql серверная

(52) кроме количества пользователей сие ещё зависит от конфигурации и размера базы,
БП 3.0 вполне себе в веб работает и на 10 и на 15, КА на 10-ти пользователях вряд-ли будет приемлемо работать, а ERP в файловом режиме вообще нереально использовать

(41) Можно, но это глупо. Подчеркиваю - глупо в случае тонких клиентов!
К примеру, у тебя 10-ти пользовательский хасп.
Если LM, то ключ могут использовать 10 разных компов, на которых можно открыть сколько угодно баз. (ну, сколько железо позволит). Кроме всего прочего, на любом этом компе можно также открывать дополнительно базы, установленные локально, в том числе толстым клиентом  (ОФ). К примеру, все работают на сервер с одной базой, а тебе нужно что-то поработать на компе локально с копией базы.

если не использовать LM, а раздавать через веб-сервер, то ключик сожрут 10 сеансов. Всего лишь 10 сеансов. И, вдобавок, ты не сможешь работать локально с другой базой (что-нибудь локально программить, к примеру).
Одним словом - расточительно.


Раздавать железный ключик через веб-сервер надо исключительно в случае, если ты цепляешься к веб-серверу не тонким клиентом, а веб-клиентом. Надо ли тебе это? Чем не устраивает тонкий клиент по сравнению с веб-клиентом? Стоит ли такая расточительность того?

(56) Полезная информация, очередной вам респект и благодарность, всё становится более понятным!

Позвольте еще немного злоупотребить вашим опытом и знаниями, как вы считаете, всё-таки старый, добрый аппаратный ключ будет универсальнее и практичнее заказывать, чем программные с пин-кодами?
Должен заметить, что ознакомившись с общим принципом работы программных лицензий у 1С, я стал склоняться к аппаратным ключам, возможно что ошибаюсь и не прав.
Насколько я понял, привязка лицензии к устанавливаемому железу довольно жёсткая; шаг влево, шаг вправо—растрел ;), даже время и дата установки Windows привязывается к лицензии.
Выходит, что при возникновении различных проблемных ситуаций с компьютером, программных или железных, которые могут повлечь за собой необходимость переустановки ОСь и как следствие заморочек с запросом в 1С новых Пин-Кодов активации. То есть, если я не ошибаюсь, что даже при переустановке 1с на тот же компьютер с тем же самым набором железа, центр выдачи лицензий потребует активации и расхода нового пин-кода и тем более, если компьютер или что-то в компьютере понадобится проапрагейдить.
Аппаратный ключ представляется более удобным решением при таком подходе лицензирования, — воткнул и порядок, хоть винду каждый месяц переставляй, он хоть и по-дороже, но может стоить переплатить и не задумываться о том, как потом объяснять 1С почему я переставляю систему и активирую новый пин-код.
Или я ошибаюсь ?

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

(0) У Вас ошибка в понимании того, что публикация на веб сервере "плодит сущности". Напротив, публикация на веб эти сущности... уменьшает, и ... упрощает архитектуру. (Могу прямо по пунктам показать как)

(59) Согласен, уже осознал свою ошибку.

(0) не понятно что за конфа, не понятна на какой платформе.
При публикации файловой базы в 1 момент времени только 1 чел будет проводить операции с БД (выборка, добавление и т.п.)... как-то так.

Какая цель всего этого действа?
Сколько сеансов пиковая нагрузка?

*1 чел = 1 сеанс

(61) э..мм.. не читатель?
конфа -> (4)
железо-> (5)

(61) " 1 чел будет проводить операции с БД (выборка"

Что, правда? Даже чтение монопольно будет? О_о

(64) Прямо в адресное пространство веб-сервера загружается компонент для работы с файловой базой данных и сами данные информационной базы. При этом нагрузка на веб-сервер значительно возрастает, а пользователи одной информационной базы не имеют возможности работать параллельно. Все их запросы к базе данных выстраиваются в одну очередь.
По этой причине такой вариант работы является скорее тестовым. Чтобы, например, попробовать, как информационная база работает через веб-сервер, с веб-клиентом. В качестве рабочего такой вариант, наверное, можно использовать в особенных случаях для очень небольших рабочих групп.
https://v8.1c.ru/platforma/faylovyy-variant-raboty/

(63) ну раз комп такой с его слов норм - пусть юзера работают через терминальные сессии, будет всяко быстрее чем по сети с файловой базой и тем более быстрее чем через веб

(66) Неа нифига файловая в RDP не быстрее ибо взаимоблокировки
Обычно быстрее последовательно с базой работать по очереди чем одновременно пытаться

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

(65) Я бы сказал, что "тестовым" следует считать файл-серверный доступ к базе. Здесь 1с явно пургу гонит.

Буквально недавно сталкивался с этим вопросом.
И бухи довольны как слоники и я доволен что они довольны.

Пока никаких проблем не обнаружилось.
А через шару дошла база до повреждения файла 1CD.
Восстановил с трудом и сразу на веб-сервер.
Надо было намного раньше это сделать

(68) Ну, вероятно следует полагать, что 1С заинтересована в потенциальных покупателях лицензий на Клиент-Серверную архитектуру. Точнее говоря, хотелось бы чтобы 1С руководствовалась именно маркетинговыми соображениями в "гоне этой пурги". ;)

(68)Пургу? И это пишет фантазёр, который придумал "файл-серверный" доступа к базе!

(70) а давайте вы немного прокачаете скилы по 1С прежде чем критиковать то, работу чего не понимаете.

(67) зависит от характера работы, я даже сколько у него в пике сеансов не знаю.... у него там возможно всё, вплоть до буферизации пакетов на стороне сервера (и такое чудо встречал)...

Как-то так

(71) Что не так с концепцией "файл-сервер"? Всю жизнь так сетевые шары назывались.

(75) например тем, что вендор этого выражения не употребляет.

(0) Файловую базу любой юзер может грохнуть. Одно это перевешивает возможные недостатки публикации через web-сервер.

(19) Ну поставь watchdog, который будет рестартовать службу web-сервера если он вдруг свалится. Хотя я что-то не припомню, чтобы он валился на ровном месте.

(76) Вендор употребляет что-то другое.
"Прямо в адресное пространство веб-сервера загружается компонент для работы с файловой базой данных и сами данные информационной базы. "
Так и представил, как вся база в десяток гигабайт загружается в адресное пространство веб-сервера, ага..

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

(72) Я не критикую, наверное не так сформулировал свою мысль. Напротив, мне хочется докопаться до истины ;)
Если архитектура файловой 1с базы самодостаточная вещь в себе и её внутренней, фирменной СУБДешной составляющей достаточно для стабильной работы, то значит видимо можно и без ВебСервера обойтись и возможно даже, что он неким образом может сказываться на производительности не лучшим образом, если я правильно понял заявления 1С по информации чуть выше.
https://v8.1c.ru/platforma/faylovyy-variant-raboty/. Типа тестовый режим и прочее.
Тогда я спокойно разворачиваю файловую на "шаре", без ВебСервера и смотрю дальше по производительности, если не хватает по нагрузкам, то начинаем задумываться над переходом на клиент-серверную архитектуру.

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

тема того, что файловая шара сама по себе является источником тормозов известна уже почти 30 лет.

Но я специально сейчас проверил, что именно выдает поисковик по запросу "тормозит файловая база 1с 8.3 по сети"

Правильного ответа не увидел. Поэтому и в этой ветке уже намолотили несколько десятков постов.

В ссылке постом выше сказано "Файловый вариант работы — один из вариантов работы системы «1С:Предприятие 8». Файловый вариант работы рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети."

Вопрос к ТС - будет все-таки еще пользователи кроме одного? Если ответ : вероятно, что будут - база будет однозначно тормозить при более, менее интенсивной работе пользователя с данными, причем, на достаточно современных конфигурациях торможение будет заметно сильней.
Это не лечится никак. Это ограничение протокола smb или samba , который обеспечивает многопользовательский доступ к данным, открытым на чтение-запись .
Выход только в переходе на однопользовательский доступ, который выполняется через публикацию базы с веб-сервером. И он там расписан на бытовом языке.

Есть еще вариант, как опубликовать базу - использовать встроенный автономный сервер
Вот здесь это расписано http://catalog.mista.ru/1c/articles/1165658/
там в конце есть и продолжение.

(80)///Вопрос к ТС - будет все-таки еще пользователи кроме одного? Если ответ : вероятно, что будут - база будет однозначно тормозить при более, менее интенсивной работе пользователя с данными, причем, на достаточно современных конфигурациях торможение будет заметно сильней.
Это не лечится никак. Это ограничение протокола smb или samba , который обеспечивает многопользовательский доступ к данным, открытым на чтение-запись .
Выход только в переходе на однопользовательский доступ, который выполняется через публикацию базы с веб-сервером. И он там расписан на бытовом языке.

Как понять, "еще пользователи, кроме одного" ? Будут ли с базой одновременно работать более одного пользователя по-сети ? Разумеется что ДА,!, как же иначе, зачем её вообще тогда на "шару" выкладывать ;).! Конкретно в моем случае, с файловой базой планируется обеспечить работу около 10-ти пользователей, если учитывать и удаленных пользователей, работа которых будет не постоянной. Постоянно с утра до вечера в базой взаимодействуют  6-8 человек. Как там с вирусом дела пойдут не известно конечно, если предстоящий год будет так же вяло течь в плане организации работы, то не знаю, может часть постоянников уйдут еще на удалёнку, а может не уйдут, а просто еще новых наймут, сложно прогнозировать, все возможно, вплоть до закрытия конторы вообще ;).

(80) Файловая база опубликованная на ВебСервере работает в "Однопользовательском" доступе ? Что это в полном смысле значит? Это ведь не должно значить, что только один пользователь может работать с базой, а что тогда ?

Вообщем, я так понимаю, что надо будет поднимать вопрос о покупке лицензии на полноценный 1С сервер ;) и переходить на Клиент-Серверную архитектуру. Мини-сервер по лицензиям маловат уже.
Слышал, что если 1С сервер на Линукс к подключениям более демократичен, там без серверной лицензии вроде как до 10 пользователей обслуживается, хотя мнения разделяются, кто-то пишет, что раньше так было и с новыми версиями платформы уже блокируются подключения более 3-х пользователей к серверу.
Кто нибудь владеет точной информацией?

(82) Это означает, что веб-сервер получает доступ к файловой базе одним сеансом. С точки зрения файловой системы файл базы и остальные файлы в каталоге базы (там временные и служебные) на чтение-запись открыт только одним пользователем. Внутри сервера пользователей много.

Если что, то в скл-субд сделано практически также - один пользователь от сервера к файлу или файлам СУБД, а уже внутри себя СУБД сама обеспечивает наличие множества сеансов с множеством пользователей.

(83) > без серверной лицензии вроде как до 10 пользователей обслуживается
Технически можно, юридически нельзя.

(83) Ну все равно же тестить придется, прежде чем в продакшн побежишь. Заметь, что именно линукс установка нужна.

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

и я что-то не припомню, чтоб хоть кто-то ставил мини-сервер на линуксовую ось :-)

(86) Хм.. а вроде бы мини-сервер считает сеансы, а не соединения.. и финт ушами с мультиплексированием не пройдет.

(88) не проверял

(87) Логично, если на Linux подключение до 10 пользователей к серверу халявные, то на 5 лицензий мини-сервер нет смысла покупать. ;)