Имя: Пароль:
1C
 
Как добиться стабильности работы в условиях работы тонкого клиента?
,
0 squidw
 
26.06.19
17:37
Доброго времени суток.
Есть два территориально разделенных офиса. На первом офисе WS2016 + сервер 1с 8.3.13.1690 +СУБД PostgreSQL, на втором офисе ПК работают через тонкий клиент 1с. Офисы соединены VPN. С точки зрения минимизации трафика указан параметр подключения ClientConnectionSpeed=Low. Канал на первом офисе максимум 5Мбит/сек от провайдера + канал не очень стабилен. Решено было развернуть на сервере первого офиса Hyper-V и поднять там же ВМ RDP и запустить пользователей туда. Работа стала стабильнее и без глюков, однако это большее количество уязвимостей и больше накладных расходов на обслуживание лишнего сервера RDP + по деньгам много. У клиента типовые конфигурации БП, ЗУП, УТАП. Отсюда вопросы:
1. Есть ли разница при подключении тонкий клиент и веб-база прописанная через тонкий клиент с точки зрения стабильности соединения и количества трафика?
2. Какие есть варианты уменьшения трафика в режиме тонкого клиента кроме параметра ClientConnectionSpeed=Low?
3. Есть хоть какая-то отсылка по официальной документации 1с по данным вопросам? Я находил только это что не много:
https://1cfresh.com/articles/work_slowconnection
https://its.1c.ru/db/v8313doc#bookmark:dev:TI000001242
1 H A D G E H O G s
 
26.06.19
18:22
Web-сервер, че тут думать то?
2 Мимохожий Однако
 
26.06.19
18:24
Переводи на веб-клиентов.
3 squidw
 
26.06.19
20:08
(1) (2) А хоть какая-то аргументация есть в сторону тонкого клиента с веб базой по сравнению с тонким клиентом или тем более RDP. Я знаю как настраивать веб базы и делал это не раз, но в данном случае постоянно оглядка на стабильность и скорость канала.
4 Провинциальный 1сник
 
26.06.19
20:14
(3) По трафику что сервер приложений, что веб-сервер - примерно цифры одного порядка. И по стабильности тоже. Да, и ClientConnectionSpeed=Low это лишнее. У вас же не диалап.
5 Провинциальный 1сник
 
26.06.19
20:16
+(4) Тонкий клиент очень мало трафика ест при обычной работе, за исключением особых случаев типа передачи файла с клиента на сервер или обратно.
6 Фрэнки
 
26.06.19
20:29
(3) если все будет находиться внутри VPN, то установленный тонкий клиент будет вполне адекватен и нормально вписываться в имеющиеся 5 мбит.

Другое дело, что эти 5 мбит скорей всего забивают всякой дрянью, которая к 1С ни коим боком не относится.

Но...! Когда поднимаешь RDP-сеанс, то дальше уже без вариантов : какой-то условно стабильный поток из имеющихся 5 мбит отдается на отрисовку картинки в RDP и все. Весь остальной вероятный расход трафика ложится полностью на сторону раздающего, который кроме картинки экрана ничего не передает.

А может у вас проблема как раз на стороне раздающего RDP-сеансы, а пытаетесь лечить совсем в другом месте?
7 squidw
 
26.06.19
23:25
(6) Когда в данном случае я поднял RDP на том же сервере виртуалкой, то вопросы отпали с залипанием и зависанием функционала конфигурации и запуска. Проблемы когда без RDP голый тонкий клиент 1с запускается до сервера 1с непосредственно по VPN до первого офиса.
Тут вопрос не в том что канал забивается чем попало, а в том что сам канал не стабилен, то есть частые потери пакетов в сети,, банальный пинг даже бывает из 200 пакетов потеряет 50, что много.
8 Провинциальный 1сник
 
27.06.19
08:02
(7) Вот как раз требования к стабильности канала у тонкого клиента очень невысокие, примерно как у сервисов яндекса. Для рдп требуется на порядок стабильнее канал. Если у вас тупит тонкий клиент - значит вы что-то делаете не так. Обращаетесь по имени или по IP?
9 Сияющий в темноте
 
27.06.19
09:04
подвисание интерфейса-мы пошли на сервер,но соединение долго устанавливается.
проверяйте настройки маршрутизации,чтобы не было долгого ожидания
веб клиент не спасет,если только апача не будет держать соединенин открытым.
и это,открытое соединение нужнл продувать пакетами,а то оно как бы с концов открыто,но по дороге уже порвалось
рдп просто пиодувает соединеин пакетами рисования.
10 Провинциальный 1сник
 
27.06.19
09:09
(9) Ага. В тонком клиенте, грубо говоря, каждый серверный вызов - новое tcp-соединение. Соответственно, тормоза могут быть при долгой инициализации tcp, а если сервер задан именем - то еще и при преобразовании имени в адрес. И то и другое - ненормально.
11 Йохохо
 
27.06.19
09:21
(7) есть бородатая настройка про которую забывают, поставьте на сетевухе 10мб фул дуплекс или даже полудуплекс. Когда то это решало с доморощенными провайдерами
12 squidw
 
27.06.19
09:51
(8) (9) (10) В моем случае обращение идет по IP. На сетевое оборудование у меня доступа нет, этим занимается сторонняя организация, которая доступа не дает.

(11) А вот тут не понял. Есть 1Гбит/сек физические сетевые адаптеры в количестве 3. 1 для IPMI и еще 2 для самого сервера. Программная настройка? А зачем 10мб, вы советуете занизить программно скорость адаптера, для чего? Есть отсылка как это выполнить и для чего это надо?
13 squidw
 
27.06.19
10:01
(12) В диспетчере устройств в дополнительных настройках сетевого адаптера раздел "SPEED & DUPLEX" текущее значение "Auto Negotiation", я так понял согласование. Кроме этого есть "1.0 Gbps Full Duplex", я так понял и принимать и посылать пакеты одновременно а не по очереди. Подводные камни есть какие-то есть выставить "1.0 Gbps Full Duplex"? Никогда не лазил сюда. Есть смысл вообще ставить данный параметр?
14 Провинциальный 1сник
 
27.06.19
10:03
(13) Не заморачивайся. Вряд ли проблема в этом. Антивируса на сервере или на клиенте случайно нет? Он не проверяет сетевой трафик?
15 squidw
 
27.06.19
11:27
(14) На сервере антивирусов нет, только стандартные защитник и брандмауэр с исключениями для процессов и каталогов 1с, СУБД.
На ПК от места к месту есть, а где-то нет антивирусов, на ситуацию не влияет.
16 Йохохо
 
27.06.19
11:43
(12) "бывает из 200 пакетов потеряет 50, что много" от этого может помочь. Но вообще надо провайдеру уши намять
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший