Привет! Развернул базу на шаре SMB, удаленные объекты связаны туннелем GRE роутерами. На центральном узле, где выложил базу выделенка 100 мегабит, синхронная, на удаленном узле 50 мегабит только. База на SSD Харде, процессор не фонтан, i5 четвертого поколения, 16мб. оперативки.
Короче производительность конечно оставляет желать лучшего, пустая база удаленно открывается секунд 20-30, работа медленная, как-бы не смертельно конечно, но особое удовольствие не испытываешь, ожидания, думаю по мере разрастания базы станет еще хуже.
Это так и должно быть при таких вводных параметрах или копать железо на проблемы? Платформа 8.3.17., конфигурация Розница 2.3. Конечно хотелось бы обойтись без РИБ, но при такой медлительности видимо другого варианта нет.
Что посоветуете,?

(1) Спасибо, попробую! А поможет? Доступ-то всё равно нужен через тонкий клиент к базе на шаре, через браузер работать не получится, надо оборудование подключать.
Или всё равно наличие веб-сервера положительно скажется на производительности ?

синхронная - симметричная
SSD Хард не бывает
через тонкий клиент к базе на шаре - через тонкий клиент к апачу
100 мегабит через (1), хватит 1 мегабайт)

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

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

(5) И главный момент, можно ли будет без ограничений работать с оборудованием при таком доступе к базе, опубликованной на веб-сервере? Мне будет нужно как минимум ККТ или терминал эквайринга подключать и желательно еще штрих-ридер и принтер этикеток.

Уже поднял кстати Apache, пока трепался, ну что могу сказать, впечатляет скорость,!! Небо и земля в сравнении с работой через каталог до шары.!! Спасибо огромное всем, кто открыл мне глаза на такой способ, !
Теперь главное разобраться, что будет с оборудованием, пропишется все нормально?

Это получается на SAAS, коммерческих, облачных 1с тоже доступ настроен к веб-серверу, так всё шустро работает, а я-то думал как так выходит, у меня тормоза дикие, значит веб-сервер публикуется.!

Я правильно понимаю, что при опубликованной на веб-сервере базе и доступе к ней через тонкий клиент, то платформу на удаленных точках ставить не нужно, можно только тонкий клиент? Тогда как железо встанет, БПО подгрузиться тоже? Или платформу надо ставить?

Вообще, как думаете, правильно будет торговый объект, подключать в режиме тонкого клиента к базе на веб-сервере? Точки в первую очередь "Фронт" кассовый, ну и немного бэк тоже, товар принят, перемещение оформить, инвентаризацию провести, ценники этикетки распечатать. Или же при таких задачах лучше локально через РИБ настраивать?

А тонкий клиент это разве не платформа?

(11) Ну, я в терминологии 1с могу ошибаться, но в плане инструментария для доступа к базе у 1с есть дистрибутивы именно тонких клиентов для различных платформ, Вин, Линукс, МакОС, которые вроде как, если я конечно не ошибаюсь загружаются и устанавливаются и лицензии не требуют. Вот к примеру я открывал на фрешах базы, ну всякие облачные 1с, сейчас полно таких хостеров, вы знаете сами. И собственно там как бы есть пакеты, дистрибутивы тонких клиентов для доступа к базе. То есть основной способ работы через RDP клиент, но можно и скачать, поставить и использовать тонкий клиент и через него работать с базой.
Этот тонкий клиент платформа ? Они по весу тоже небольшие кстати.

Вот смотрю сейчас на сайте 1C:Обновление программ https://releases.1c.ru/total

Доступно к скачиванию "Технологическая платформа 8.3, версия 8.3.17.1549", размер которой под 600 мегабайт и отдельно можно скачать "Тонкий клиент 1С:Предприятия для Windows", который весит всего 100 мегабайт, ну или можно еще для других операционнок скачать тоже, под Linux, macOS.

Я ради эксперимента, снёс платформу на удаленной точке, поставил "Тонкий клиент", настроил доступ к базе на Веб-Сервер, прописал в тонком клиенте  в формате http://moyserver.ru.
База загружается, лицензию не просит, вроде работает и довольно шустро.

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

Или платформу поставить полную с локальной базой и РИБ настроить? Что скажете уважаемые специалисты-автоматизаторы?

Понятно что основной плюс РИБа и локальной базы в том, что точка будет работать и при отсутствие связи с Центральной Базой, а потом при восстановлении соединения синхронизирует все что офлайн накопилось. А одна база на все удаленные точки конечно стрёмновато, — упадёт веб-сервер, 1с или вообще комп. центральный накроется медным тазом, то все точки встанут и торговля встанет. РИБ в этом плане отказоустойчивость несёт в себе, это я понимаю.

Но если этот вопрос опустить и сравнивать только по функционалу работы, то отличия какие могут быть при работе с тонким клиентом по базе на веб-сервере?

(14) С точки зрения функционала - по идее разницы быть не должно.
С точки зрения отказоустойчивости - нужно брать статистику по доступности канала связи. Может оказаться что со светом проблем больше чем со связью.
  
Что касается отказоустойчивости РИБа - тут тоже не все так однозначно.
1. Если использовать РИБ - компы на кассах нужно существенно мощнее, чем при использовании тонкого клиента.
2. Отказоустойчивость и производительность сервера - обеспечить проще и дешевле, чем отказоустойчивость обычного компа.
3. Помимо железных проблем - при использовании РИБа возникают всякие программные проблемы - конфликты, коллизии, задержки при синхронизации (особенно при работе всяких бонусных и скидочных программ). Повышается трудоемкость обновления (а Розницу в современных условиях постоянного развития 54-ФЗ и систем маркировки - приходится постоянно поддерживать в актуальном состоянии)
  
Поэтому ИМХО при прочих равных - если на канале хотя бы 4 девятки - то лучше использовать тонкий клиент + Веб, чем РИБ.
  
З.Ы. из личной статистики использования РИБ - один раз накрылся сервер - сломался кондюк, перегерелись диски - накрылся рейд. После этого админы настояли на использовании РИБ для обеспечения отказоустойчивости - с тех пор дважды из-за отключения света падали узлы на кассах.

(15) О, а я уже не надеялся получить ответ, спасибо большое за такой подробный анализ и объяснения! Работа в режиме тонкого клиента+веб конечно очень удобна, и вообще как вы справедливо подметили по многим аспектам логичнее, если конечно стабильно будет база в таком режиме работать, я имею ввиду в опубликованном на веб-сервере и с доступом по тонкому клиенту.
А если в плане взаимодействия с подключенным, кассовым железом тоже разницы принципиальной нет, то однозначно буду делать упор на обеспечение отказоустойчивости центральной базы/сервера, — оснастить рейдом, бесперебойник само собой, повысить производительность еще может и пр. необходимые действия в этом плане. По хорошему может и саму машину поменять при первой возможности на серверное железо, чтобы и БП двойной стоял и охлаждение и ecc память и прочие серверные плюшки отказоустойчивости и оперативного восстановления при сбоях.

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

Думаю, продолжить немного погонять работу с базой в таком режиме, настроить связь с кассовым железом и посмотреть результат. Надеюсь, что База+ВебСервер+ТонкийКлиент подойдет к требованиям автоматизации магазина и станет лучшим выбором, чем локальные, оффлайн базы + РИБ.

(15) "Если использовать РИБ - компы на кассах нужно существенно мощнее, чем при использовании тонкого клиента."
- а почему это? РИБ - это же только обмены (если я правильно понимаю?), обмены могут быть редкие, что тогда будет нагружать комп?

(17) Сама база. причем в файловом режиме.

(16) Как раз недавно сменили РИБ у одного из клиентов, который работал с 2005 года (еще с 7.7 и флешек) на Веб публикацию.
Когда переводили проверяли разницу между работой в РДП и публикацией базы при работе с ККМ - через РДП чек по 30-40 секунд мог печататься. Через Веб клиента - практически сразу.

(19) так тут нет РДП. Локальный комп.

(10) Все отлично будет с оборудованием, у меня сеть из 12 магазинов так работает, через апач до сервера.

(16) добро пожаловать в 2020

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

(19) (22) (21) Работа Тонкого клиента с файловой БД+ВебСервер конечно оставляет только лучшие впечатления, всё более чем хорошо, особенно представьте мои ощущения, человека который с вашей помощью только вчера узнал, что тонким клиентом можно полноценно работать с БД, если поднять на 1с веб-сервер, я то думал это дело не более чем для простеньких отчетов и простых манипуляций с базой предназначено, для редкой работы руководителя, оказалось, что я сильно ошибался.

Но, несмотря на всё, хочу сказать, что довольно СТРАШНОВАТО всё же решиться на такой поступок для торговых точек, когда понимаешь, что чуть что не так с доступом к серверу и работа/торговля просто ВСТАЕТ наглухо, ! И вот это "чуть что" реально пугает и теоретически его довольно много; сбои местного провайдера связи, неполадки сетевого оборудования/маршрутизатора, падение туннелей, стабильность железа сервера, программные косяки сервера, операционки, самой 1с, веб-сервера... Все это очень сильно напрягает, — шаг влево, шаг вправо — расстрел.
Сколько может уйти времени на восстановление при таких сбоях, как это отразится на торговой точке, как много покупателей потеряет торговый объект, пока все это дело придется поднимать... Все эти вопросы сложные и довольно ответственно принять решение при таком положении дел.

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

Или я слишком труслив ?

(19) (21) У вас 12 магазинов это такой один клиент с 12-ю филиалами удаленными, который работает через "Тонкий+ВебСервер" ?
Все 12 удаленных объектов подключаются к файловой БД через тонкий клиент или это уже у вас 1с в серверном варианте настроена?
12 точек конечно круто, как производительность, нормально работают, не жалуются? Какой оборудование используете в качестве сервера если не секрет?

(24) "Или я слишком труслив?" жаба питает трусость, можете ее накормить - не надо РИБ) если чеков много можно вместо РИБ фронт на Фронтол

(26) Чеков на самом деле не много, даже бывают дни, что их вообще нет, ;), а когда бывают, то могут быть "спасательными" для бизнеса, поэтому и страшно, что если в такой момент связи вдруг не будет, то продавец ни товар подобрать не сможет по базе, ни продать по кассе, ни принять деньги по эквайрингу.

А почему именно Фронтол советуете? У него какая-то особенность при работе с оффлайн базой? Если в "смешанном" режиме сделать, но на РИБ, не лучше? Чтобы всё на 1с было.

(27) РМК фронтол подбирает товары мгновенно. У меня в "сложном" месте стоит миникомп Фронтол Оптима на аккумуляторе с ут 10.3 риб, на нем слабенький диск, но мб потянет розницу раз в пятилетку, но все равно РИБ через веб сервер. "всё на 1с было" - конечно с такими чеками

(26) Фронтол смотрел как-то, в общих чертах, поверхностно, версию 5-ю кажется, по-настройкам пробегался, документацию по интеграции вроде тоже, но уже честно говоря ничего не помню, там база локальная под управлением СУБД FireBird насколько успел понять, но какие-то грубые методы обмена, через директорию сетевую, но насколько эти обмены с товароучейтной системой стабильно будут работать?

Я не знаю как у Атол с современными версиями Фронтола, но то что я видел в плане настроек, это такой привет из 80-х был, Виндоуз 95 эдакий. 1с конечно тоже не Apple в плане дизайна UI, ;), но как-то роднее что-ли ;), привычнее, логичнее, интуитивно понятнее, впрочем чтобы понять логику бизнес процесса даже в простой Рознице иногда долго нужно вникать, это да.

Если у Фронтол есть преимущества для моего случая, то конечно можно предпочесть, я думаю и надеюсь современные версии будут более дружелюбными и к пользователю и админу.

(29) "Если у Фронтол есть преимущества для моего случая" нету, продажи калечные, Фронтол для потока, ну или может заменить РИБ

(28) Мне для полного счастья и спокойствия в режиме Тонкий + 1сВебСервер не хватает на клиентах механизма для хоть какой нибудь малейшей автономности, работы системы. Если бы при отсутствии связи с сервером на Тонком клиенте оставалась бы возможность оффлайн работы хотя бы с оборудованием, — чек пробить вручную, без.нал провести через терминал эквайринга, то наверное спокойнее было. А так каюк полный работе,  тушите свет.

(30)розница на хорошем компе локально разве поток не тянет? по моему вполне себе.

(32) подбор точно нет
(31) 2 ярлыка, тонкий в основную и риб

(31) Тебе кто мешает юзать Розницу в связке бэк через веб + фронт на РИБ по кассам?

(33)Если товар штрихкодирован то можно пробовать.

(33) Все тянет (поток в аптеке как минимум) но комп нужен хороший

(36)+ И да там именно подбор ибо ШК кривые у половины или выдает несколько серий и надо еще выбрать нужную

Кстати новый фронтол не шустрей Розница 2 работает.
И там куча косяков

(36) "комп нужен хороший" на фронтол оптима стоит одна сд карта )

(33) (34) Вы имеете ввиду, что все же настроить в базе РИБ обмен, создать на Центральном Узле базы для Подчиненных Узлов, развернуть их локально на кассах, вынести дополнительные ярлычки для доступа к локальной базе на случай аварии сервера при работе с Тонким Клиентом?  Но основную работу на кассах настроить на режим Тонкого ?
Или же Кассы локально исключительно настроить, по РИБ чтобы обмен был и Тонкий доступ вообще не использовать на кассах. И только для Бэка пользовать Тонкий клиент?

(40) На твое усмотрение, но не забыть сделать автообмен для риба принудительный

(40) да, но замучаешься учить персонал, им это и в след жизни не уперлось

(33) //// 2 ярлыка, тонкий в основную и риб

А если на основной базе, на сервере поднимать обмен по РИБ, то есть настроить, потом разумеется физически разнести базы по Подчиненным Узлам, положить ярлычки на эту базу на пожарный случай, но такой режим оставить только на "пожарный случай", а работать всем кассам в режиме Тонкого, то как будет? Настроенный и не используемый РИБ конфликтовать не будет?

Суть в том, что с файловой базой в любом случае желательно работать через веб-сервер. Шансы разрушить базу при сбоях при работе через сетевую шару весьма отличны от нуля.
Если уж заморачиваться с РИБ, то лучше делать это основным вариантом работы, а не резервным.

РИБ присмотра требует и при основном варианте работы присмотр будет происходить естественным образом. Плюс на полную будет использоваться плюшка, когда основная база "гальванически" развязана с магазинами. Т.е. больше свободы будет при выборе времени регламентных работ и т.п.

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

Если чисто для резерва и очень редко то это можно вручную разруливать после сбоя и такой работы на автономной риб базе на кассе.
Причем можно сделать что автоматически запускает локальную РИБ базу если недоступна по сети центральная

(23) /// Тонкий является тонким только тогда, когда есть некий другой условный сервер, которые этому "тонкому" выдает все необходимое для тонкой работы - а когда его нет, то тонкий срочно потолстеет, чтобы сам себя обеспечить всеми этими ресурсами.

Да, очень интересный момент затронули! Интуитивно заметно кстати, когда запускаешь Тонкий для доступа к 1сВебСервер, всё шустро значительно, если сравнивать работу с локальной базой. Я просто последние дня три-четыре только этим и занимался, то есть настройкой и периодическими запусками базы в локальном режиме, уже как-бы ритмически время работы и производительность начал ощущать. А когда подцепился к файловой базе развернутой на веб-сервере, то реально почувствовал прирост производительности, как при запуске, так и дальнейшей работе.

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

(47) можно к локальной базе тоже через апач же локальный
как минимум в два процесса оно пашет и если проц двухядерный а лучше четырех то значительно шустрей

(47) "то это не скажется уже на быстродействии, верно" в таком режиме тонкий статует встроенный в 1с веб сервер _на_каждом_компе_с_сеансом_

(47) можно к локальной базе тоже через апач же локальный

Хорошая идея, спасибо, попробую!

(44) ////Суть в том, что с файловой базой в любом случае желательно работать через веб-сервер

А если поднять 1с сервер, кластер, с СУБД, не важно ms sql или Postgres и подключаться уже Тонким на него, то это по быстродействию и эффективности будет сильно отличаться от файловой базы 1с + ВебСервер Апач или IIS. ?

(51) кардинально улучшится только параллельность работы

(44)////Суть в том, что с файловой базой в любом случае желательно работать через веб-сервер

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

(53) "точек смысла нет заморачиваться с сервером" это же прекрасный плюс для потфолио

(53) хе попробуй затестить бесплатный автономный сервер от 1С

(52) ////кардинально улучшится только параллельность работы

То есть одновременная работа пользователей с базой, верно?

(56) для одновременности можно несколько процессов апача на разных портах к одной базе файловой

(56) да, компонента веб сервера однопоточная

(55) ////хе попробуй затестить бесплатный автономный сервер от 1С

Вы имеете ввиду облачные серверы 1С, типа фрешей и 1сСloudRU и подобных? Открывал тестовые аккаунты, было дело, но честно говоря не могу сказать прямо удалось потестить, погнать для своих задач, больше поигрался наверное. Так чтобы нагрузить пользователями удаленными толком не получилось.

Кстати, если вы о этих провайдерах, то они в основном доступ к файловой 1с обеспечивают насколько я понял, по-крайне мере тестовый было так.

(59) неа подразумевал бету http://catalog.mista.ru/public/1165658/

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

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

То есть если у нас на начальном этапе 3 удаленные торговые точки, (по одному пользователю в каждом, не частая работа, всего пользователей БД не более 5-7-ти) которые посредством Тонкого клиента будут подключаться к файловой 1с+ВебСервер, то какое жалезо будет нормально тянуть это добро?

Процессор i7 лишним не будет, какое поколение есть смысл выбирать? 16-32гб оперативки ? Рейд железный организовать на машине? Ну бесперебойник, хорошие кулеры, то да сё опускаем, это понятно. Накопитель SSD только.

Смотреть в сторону Xeon на серверной платформе с памятью ECC и остальными серверным плюшками по дублированию и прочим, есть смысл в моем случае или это избыточно будет слишком ?

(61) селерон на любой помойке с 4гб оперативы и ссд

(60) ////неа подразумевал бету http://catalog.mista.ru/public/1165658/

очень любопытно, спасибо за ссылку, почитаю.

(62) ////селерон на любой помойке с 4гб оперативы и ссд

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

(64) конечно, не в рдп а тонким изи

(64) Но у тебя же база Розница.
В однопоточном вебсервере получишь процесс для работы с базой который больше 4 гб не съест. И удаленные пользователи с разумном количестве с разумными запросами вполне себе смогут выжить.

Тебе сколько надо клиентских сеансов?

(64) Для работы современных УФ конф 1С надо минимум 4 гига рам на "сервер" и 4 гига на "клиент"
Короче если сервер и клиент на одной машине то минимум 8 гигов а лучше уже 16

Если разнесены то и по 4 гига хватит в обрез. Файловая через веб она в однопотоке, т.е. несколько клиентов тонких или веб один сервер по очереди мучают.
Короче да 4 гиг на "сервер" файловый в принципе хватит для хз сколько клиентов, но клиенты если их много устанут ждать пока там у кого то "отчет доформируется" ))

(67) там 5 кассиров, им гига на пятерых хватит

(68) Один тяжелый серверный запрос, аля фоновое может скушать 10 гиг

(69) На рабочих местах кассиров и в Рознице таких запросов не должно быть.

Но чем больше пользователей, тем выше вероятность, что кто-то сможет нечто тяжелое запустить, а кто-то из остальных в этот момент тоже к базе обратится

(70) резать интерфейс и права.

Для связки 1с+ВебСервер в качестве веб-сервера на Win10LTSC что предпочтительней использовать на ваш взгляд, "родной" для винды IIS ? Или Apache оставить?
Сейчас стоит Apache, хотя вначале стал IIS запускать, но не получилось, с битностью винды и 1с-ки несоответствия вроде как, у меня винда 64-битная стоит, 1с 32 битный. Ну, это не важно, разобраться можно, скорее всего IIS как-то правиться.
Главное понять, что эффективнее и стабильнее будет для 1с-ки, Apache или IIS ?

(72) У тебя 1с на 32 бита обосновано чем-то?
Торговое какое-то установлено, которого нет в версии на 64-бит?

(72) чисто технически эффективность и стабильность, в контексте до десятка магазинов розницы, пускай даже по паре касс и отдельному администратору в каждом, окажутся примерно равны. быстрее упрёшся в производительность файловой базы.
потому эти вопросы перетакают из плоскости технологий и кода в область установки, настройки и обслуживания - от радиуса кривизны лапок.
публика IIS или Apache для 1С голосует за апач. со времен того треда ничего суперски не изменилось в вопросах публикации 1с в веб.

(72) Серверную часть и апач лучше 64 бит, клиенты тонкие можно и 32 если ТО требует типа эквайринга недоделанного дров

(72) на "серверной" стороне лучше таки платформу 64 ставить. иначе горе придёт, когда несколько юзеров упрутся в предел оперативки для 32 битных приложений.

(73) ////Торговое какое-то установлено, которого нет в версии на 64-бит?
Да, на удаленных объектах, на фронте оборудование, у которого проблемы с 64 битными дровами и на уровне ОС и на уровне 1с, терминал эквайринга в первую очередь, поэтому по привычке и на сервере накатил 32-битную пока, но это тестовый вариант еще, можно конечно уже 64 битную поднимать на сервере, а на узлах 32 бита оставить.

(75) (76) Да, согласен с вами, оперативку добил до 16 гб. на машинке, 32битный выше 4гб. не попользует, надо перелезать на 64битный. Я по привычке, как на узлах разворачивал, так и на сервере накатил 32 бит.

(78) клиент 32 норм к сервер 64

(77) на кой серверу 32 бит? у него же нет доступа к драйверам торг-оборудования.
В принципе, и клиенту на 32 бит уже не долго жить осталось. Затык только лишь в наличии актуальных версий драйверов.

(78) это не по привычке, а тупость. извиняйте за грубое высказывание.

(80) Для документооборота уже 3 года не могут запилить драйвер сканера 64 бит.
С ТО все еще хуже, штрихи драйвера ККТ 64 нету, а уж эквайринг так это тихий ужас, ладно 64 нет ни у кого так еще и в типовых ВК для сбера нерабочие 32, постоянные глюки и сверку итогов не делает.

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

впрочем, с драйверами в линукс проблема аналогичная. Но меня веселит порой накидывание каках на линукс-решения и рассуждения о том, что 1С похерит версию для линукс не пойми почему.

(1) ////апач блин поставь

Меня всё еще гложет один вопрос, просто хотелось бы уяснить для общего развития, если подскажете буду признателен.
Доступ к 1С файловой БД удаленно через толстый клиент дико тормозит, если просто в шару путь указывать, а через ВебСервер просто песня. !
Вот я подумал, этот ВебСервер ведь не всегда был в 1с, опубликовать базу на IIS или Apache на 8-ке 1с стало возможно, верно, раньше не было? Или на 7.7 тоже было?  Просто интересно, как раньше файловую базу удаленно использовали люди?

через цитрикс

(86) обычного rdp хватало многим, цитрикс это доп плюшки типа возврата в свой сеанс и прочих автозапусков

(86) ////через цитрикс

То есть механизмами удаленного рабочего стола, окружения, типа RDP протокола?

(88) как 100 лет назад так и сейчас для файловой шары разницы нет, что 7 что 8

(87) (89) Ну, а чтобы организовать RDP для пользователей это ведь нужно было Терминальный Сервер поднимать на серверной Виндоуз.
А просто чтобы БД кинуть в файловую шару на какой нибудь Windows 95/98 и работать с ней удаленно, это уже тормоза ?

(90) на novell netware было чуть пошустрее 77

(90) да, зачем тебе это??

(91)+ там фишка в хитрых файловых блокировках

(91) сейчас тоже)

(92) Ну, как сказать, гложет наверное, хочу понять суть в общих чертах и как бы заложить верную основу на основе этого.

Обсуждение работы файловой базы и веб-сервера в этой теме немного "открыли" мне глаза на принцип работы системы.

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

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

Исходя из всего этого я стал делать выводы и попытки принять правильное решение для дальнейшей работы.  

Если с опубликованной БД на ВебСервере всё радикально меняется и становится возможна комфортная работа удаленных пользователей с базой, то получается что использование 1С в серверном режиме, 1 Сервера с СУБД будет такой же комфортной как минимум ;).
Собственно выходит, что 1с придумал ВебСервер для публикации БД как простое решение и дешевую альтернативу работе в серверном режиме с 1с+Субд.

Либо мы работаем в файловом режиме, но должны как-то просто передавать "картинку" с данными, как в RDP, Терминальном сервере, тогда данные обрабатываются на месте, а пользователь видит готовое изображение.
Либо же сам сервер 1с берет на себя обработку данных и клиентам через тонкий клиент отдает уже обработанную информацию. Наподобие того как работают скриптовые языки типа php+html с mysql на вебсерверах.

А если пытаться работать БД с шары в файловом режиме, без ВебСервера, в толстом режиме, то мы получаем тормоза, потому что мы ждем когда эта база выкачается, дойдет до 1с и начнет там локально обрабатываться.

Вот теперь думаю, может вообще уже поднимать 1С Сервер с SQL тогда, если работа ВебСервера+1с Файловая эта такая эмуляция серверной работы.

(95) Ты бы лучше на досуге почитал что-то о протоколе Самба или smb , потому что именно этот протокол используется в сетях с виндой при расшаривании файловых ресурсов.
Иначе, так и будешь думать, что там чего-то куда-то выкачивается... а там нечему выкачиваться, а просто тупо тормозит на таймаутах для разделенного доступа к файлам в режиме чтение/запись. И все.
Хоть 10 мегабит, хоть 100, хоть 1000 - а скорость работы в расшаренном доступе к файловой базе будет низкой практически одинаково.

(96) В винде можно и в NFS расшарить.

(96) А в случае использования файловой БД, но при публикации базы на ВебСервере (IIS/Apache), то мы уже не по протоколу SMB будем осуществлять доступ, будет использоваться HTTP протокол, поэтому шустрее всё, я правильно понимаю ?

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

(99) Если доступ будет в пределах 1 локальной сети, то веб-сервер не нужен. Если извне, то нужен.

(98) Правильно, но даже не просто по протоколу, а именно через сервер, который исключает разделенный сетевой доступ

(99) Если мало пользователей (два, три) и они не очень интенсивно грузят сервак запросами, то файловый через вебсервер на ссд компе будет заметно шустрей.
Но его скорость упадет при добавлении пользователей. Скажем, если на серверном режиме 30 пользователей это даже немного и вообще не нагрузка, но есть сервера и на сотни пользователей.
А веб-сервер на файловой базе будет на большом числе пользователей просто подвисать, потому что он пропускает всех через один поток. Это очень зависит от характера работы, от того, что они на сервере делают. Веб-сервер поверх СУБД - можно увидеть варианты даже нескольких веб-серверов на одной субд-базе. На каждый веб-сервер своя строчка для подключения и пользователи друг другу мешают гораздо реже.

(101) Хорошо, спасибо за ответы! Значит начну с 64битной файловой пока, с опубликованным ВебСервером, с подключением клиентов через Тонкий, а там видно будет. В случае необходимости перехода на Клиент-Сервер, там вроде не сложно потом будет базу из файловой выгрузить и на сервер загрузить.
Честно говоря, особо и не готов сейчас брать на себя админство Клиент-Сервера, особенно на МС SQL. Есть небольшой опыт настройки и работы с базами mysql+php, поднимал для движков на VPS, на линуксе, CentOS+Lamp, но Микрософтовский ЭсКюЭль надо изучать наверное, что-то вылетит, потом два дня разбираться.
А с файловой из архива поднять делов-то. ;)