1c ускорить запуск толстого клиента в удаленном филиале?

Question

[Reneim]

В удаленном офисе запускается 1с в режиме толстого клиента. впн поднят на микротиках с поддержкой аппаратного ускорения RB 3011 b hap ax2. Но в случае если сбросить кэш 1с то первый запуск идёт порядка 30 минут. Можно ли это как то ускорить. MTU На тоннеле уменьшил чтоб не появлялась фрагментация. Пинг около 30мс. Лечится или у 1с куча последовательных запросов и время запуска пропорционально пингу?

Answer 1

[LollyFox]

Не поняла.
Вы пытаетсь через интернет запустить базу толстым клиентом без RDP?!
Странно, что это вообще запускается и работает.

Comments

[Reneim]

а почему недолжно?

[hint000]

Reneim,

а почему не должно?

Я не встречал людей с мега-терпением, готовых ждать запуска 30 минут. Так что обычно если минут за пять не запустилось, это уже считается как "не работает". Пять минут на запуск - это оч-ч-чень медленно.

Answer 2

[Reneim]

база sql. На объекте стоит весовая программа которая передает данные в 1с. и работает только с толстым клиентом. После очистки кэша первый запуск в толстого клиента на основной площадке занимает минут 9. На удаленной 30.

Понимаю что в идеале сделать рдп пробросить ком порт с весов и файл ключей

Comments

[Dieman666]

ну так толстый клиент может быть и на rdp сервере
так что в любом случае нужно все сажать через rdp

[Dieman666]

а вообще подключайте 1с ников, пусть копаются в неоптимизированном коде и исправляют долгий запуск.
или хотя бы своими силами обслуживайте sql базу хотя бы стандартными методами sql
если речь про ms sql, то в management studio есть все инструменты, агент sql правда нужен компонент и служба запущенная для этого.
реорганизация индекса-обновление статистики каждый день
раз в неделю по выхам перестроение индекса и затем то что выше
если ms sql старше 2012 версии, то лучше включить исправление оптимизатора запросов (query optimizer fix)
ну и естественно база sql должна быть на хорошем производительном ссд, что-то вроде samsung 980 pro/990 pro

[Reneim]

Dieman666, понятно что клиент то может быть и на рдп. но сервера рдп нет. большинство клиентов сидят в тонком клиенте. в толстом работают всего 4 рабочих места. из них всего 2 удаленных. Понимаю что в идеале это рдб но надо тогда пробрасывать еще ключи гуардант для весовой программы и ком порт.
Тут хотя бы понять это нормальное поведение толстого клиента или нет. Так как если я поднимаю впн с 1го города с основной площадкой, местный провайдер и пинги в пределах 5мс то в целом толстый клиент запускается за 10 минут. а вот удаленные площадки где пинги порядка 30мс запуск становится невыносимым. понятно что кэш не чистится специально но 1с любит при любом сбое криветь и требовать очистку кэша.

[Ziptar]

Reneim, я бы сказал, если у вас в такой схеме все стабильно работает, хоть и долго формирует кэши, то у вас вообще все хорошо. Не предназначен толстый клиент для работы с удаленными базами, и дело запросто может быть в тех самых лишних 25мс пинга. Это либо в рдп засовывать все, как уже сказали, либо поднимать базу локально, и настраивать синхронизации между базами, но это отдельная тема и отдельные трудности.

[hint000]

После очистки кэша первый запуск в толстого клиента на основной площадке занимает минут 9. На удаленной 30.

Удалённо 30 минут по такой схеме - не удивительно, как уже написали выше. А вот в локальной сети 9 минут - это дичь. У вас серьёзная проблема с производительностью. Может у вас база какая-то гигантская, на терабайт, не знаю. Но у нас базы порядка 10 - 50 ГБ открываются из локальной сети обычно быстрее, чем за полминуты (точно не засекал), а если дольше, то это намекает админу (мне), что что-то пошло не так. Замедление сразу после очистки кеша измеряется какими-то секундами.

[Reneim]

hint000, вы про какой клиент говорите? Тонкие запускаются быстро. 9 минут это Толстый без кэша
база маленькая порядка 12 гигов

[hint000]

Reneim, провёл сейчас замеры на двух серверах в двух разных компаниях. Ok, оказалось несколько медленнее, чем я сказал, но вот результаты:

1-й сервер, база 15 ГБ, тонкий клиент: 10 секунд до окна логина + 25 секунд после логина до открытия рабочего окна.

1-й сервер, база 15 ГБ, толстый клиент с кешем: 10 секунд до окна логина + 40 секунд после логина до открытия рабочего окна.

1-й сервер, база 15 ГБ, толстый клиент без кеша: 10 секунд до окна логина + 2 минуты 40 секунд после логина до открытия рабочего окна.

2-й сервер, база 85 ГБ, тонкий клиент: совпадает с 1-м сервером с точностью до пары секунд.

2-й сервер, база 85 ГБ, толстый клиент без кеша: совпадает с 1-м сервером с точностью до пары секунд.

На втором сервере я потратил на логин секунды на три больше, т.к. на первом был вход под главбухом без пароля (и такое бывает, эх). Второй сервер чуть быстрее по железу, но и база существенно больше (хотя на первом ~10 рабочих баз, а на втором две, но здесь это не важно). На обоих в момент теста сидело по несколько пользователей, но вечер пятницы и нагрузка минимальная. Оба виртуализированы. На обоих клиент запускался на терминальном сервере, на виртуалке. Но в 1-м случае эта виртуалка на одном физическом хосте с виртуалкой сервера 1С. Во 2-м случае виртуалка терминального сервера на другом физическом хосте. Т.е. различий немало. Даже удивился настолько точно совпавшим результатам - в пределах погрешности, т.к. просто одним глазом смотрел на часы, другим на окно программы.

В любом случае меньше 3 минут без кеша, считая сюда и время на ввод пароля.

Answer 3

[ko0]

При первом запуске толстого клиента, он скачивает с сервера в кэш клиента почти всю конфигурацию базы данных, если у вас там ERP2, УПП и т.п., то это сотни мегабайтов. Так как вы хотите работать - это очень плохая практика, работа вашего весового терминала может быть в любой момент парализована на 30 минут просто из-за потери нескольких пакетов при передаче через интернет+vpn и "падения" толстого клиента.
Я вам настоятельно рекомендую на весовом терминале установить автономную 1С с локальной базой ("файловой"), а результаты взвешиваний передавать в центральную "большую" 1С через интеграцию/обмен.
Например продукты Весысофт (https://vesysoft.ru/) // не реклама.

Comments

[hint000]

Я вам настоятельно рекомендую на весовом терминале установить автономную 1С с локальной базой ("файловой"), а результаты взвешиваний передавать в центральную "большую" 1С через интеграцию/обмен.

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

[Reneim]

Дак если бы ерп была я бы понял. там бухгалтерия вся база 12 гигов.

[ko0]

Reneim,
Конфигурация бухгалтерии 3.0 "весит" более 1000 Мб.
Между микротиками RBxxx вы не получите пропускную способность vpn-туннеля более ~16-20Мбит/с на передачу файлов по TCP (толстый клиент 1С), не важно какой у вас интернет, хоть 1000Мбит/с, и почти не зависит какой тип vpn используете.
Так же не важно какая у вас база - файловая или SQL, первый запуск толстого клиента 1С влечет загрузку в кэш клиента почти всей конфигурации, чтобы толстый клиент мог исполнять любой кусок кода.
То что у вас запустилось и работает это как выступление циркача-канатоходца: возможно, но недолго и в идеальных условиях.

Answer 4

[KelevraX]

Я правильно понимаю, что вы файловую базу открываете удаленно (с филиала) через впн? Если так, то лучше через впн зайти на комп с локальной базой через RDP и там открыть 1с. Или сделать публикацию информационной базы на веб-сервере.

Answer 5

[Dieman666]

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

Answer 6

[emka2k]

а в web опубликовать возможно ?