Друзья, помогите добрым советом, как считаете, тормоза в 1с могут быть связаны слишком узким каналом интернет (5мегабит) ? Сервер 1с на mssql, одна небольшая база на полтора гига, конфигурация Розница 2.3, удаленные точки связаны gre мостами на циске, все тонкие клиенты. Открылась новая точка, инет слабоват, пробросил мост, вроде было нормально по-скорости, но иногда начинаются тормоза, ввод с клавиатуры даже тормозит, фризит. Как считаете, искать сразу провайдера альтернативного с более широким каналом или копать настройки, на 5мегабит тоже можно нормально работать?

через веб-сервер тонкий клиент тормозит?

а 5мегабит это у клиента или сервера?

(0) Важна не толщина, а задержка и стабильность

5 мегабит это с запасом, если стабильный низкий пинг и нет потерь пакетов.

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

важен пинг и стабильность как сказал (3)

(0) ввод с клавиатуры может генерить запрос на сервер за номенклатурой по полям поиска или за историей ввода, так что это не показатель того, что проблема не в сети.
Но да, важна не скорость, а латентность.
Что показывает tracert до сервера?

(1) У клиента тонкий клиент 1с, на сервере mssql, веб-сервер не поднимал.

(2) 5мегабит у клиента, на сервере 100мегабит.

(3) Вот пинг с циски на клиенте до машины 1с сервер.

Sending 5, 100-byte ICMP Echos to 10.3.10.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
rt.cr

(4) пинг вроде не самый худший. Traceroute c циски такой.
Tracing the route to 10.3.10.10
VRF info: (vrf in name/id, vrf out name/id)
  1 10.100.4.1 8 msec 4 msec 4 msec
  2 10.3.200.2 4 msec 4 msec 8 msec
  3 10.3.10.10 8 msec *  12 msec

(9) несерьезно. С клиента 1с до сервера 1с покажи

И размер пакетов побольше хотя бы 1024 байт, а лучше 5000 байт

(11) Вот с клиента до машины.

C:\Users\User>ping 10.3.10.10

Pinging 10.3.10.10 with 32 bytes of data:
Reply from 10.3.10.10: bytes=32 time=3ms TTL=125
Reply from 10.3.10.10: bytes=32 time=4ms TTL=125
Reply from 10.3.10.10: bytes=32 time=4ms TTL=125
Reply from 10.3.10.10: bytes=32 time=4ms TTL=125

Ping statistics for 10.3.10.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Вот до внешнего адреса, маршрутизатора

C:\Users\User>ping 194.154.xx.xx

Pinging 194.154.xx.xx with 32 bytes of data:
Reply from 194.154.xxxx: bytes=32 time=4ms TTL=248
Reply from 194.154.xxxx: bytes=32 time=4ms TTL=248
Reply from 194.154.xxxx: bytes=32 time=4ms TTL=248
Reply from 194.154.xxxx: bytes=32 time=4ms TTL=248

Ping statistics for 194.154.xxxx:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 4ms, Average = 4ms

C:\Users\User>
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 4ms, Average = 3ms

Вот трейсинг до машины 1с.

C:\Users\User>tracert 10.3.10.10

Tracing route to rg-sr [10.3.10.10]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  10.4.33.254
  2     3 ms     4 ms     4 ms  10.100.4.1
  3    23 ms     4 ms     4 ms  10.3.200.2
  4     4 ms     4 ms     4 ms  rg-sr [10.3.10.10]

Trace complete.


Вот до публичного адреса, маршрутизатора.

C:\Users\User>tracert 194.154.73.34

Tracing route to 194.154.xxxx over a maximum of 30 hops

  1     1 ms    <1 ms     1 ms  10.4.33.254
  2     1 ms     1 ms     1 ms  xxxx-28-195.static.flexline.ru [195.28.54.1]
  3     2 ms     2 ms     1 ms  3-192-30-185.static.flexline.ru [185.30.192.3]
  4     2 ms     2 ms     7 ms  176.99.137.52.inetcom.ru [176.99.137.52]
  5     2 ms     2 ms     2 ms  195.218.178.137
  6     2 ms     2 ms     2 ms  pe27.Moscow.gldn.net [79.104.235.190]
  7     4 ms     4 ms     4 ms  194.154.xxxx

Trace complete.

А вот так с клиента?
ping -l 5120 -n 100 10.3.10.10

Ну и этот вариант слишком синтетический, т.к. на маршрутизаторах обычно ICMP протокол всегда имеет повышенный приоритет.

Можно iperf-ом проверить. Там будет более реальный вариант.

(7) вот, надо поднять вебсервер

(13) поставь пинговать минут на 5. Может у тебя тупо пакеты теряются

(14) C:\Users\User>ping -l 5120 -n 100 10.3.10.10

Pinging 10.3.10.10 with 5120 bytes of data:
Reply from 10.3.10.10: bytes=5120 time=22ms TTL=124
Reply from 10.3.10.10: bytes=5120 time=22ms TTL=124
Reply from 10.3.10.10: bytes=5120 time=22ms TTL=124

(19) По красоте все. Попробуй, как советует (17) тонкий клиент через вебсервер. Там 1с по другому работает.

(20) Да у него ipшники Московские и МО. Я один раз видел, как vpn траффик из Мск магазина в Мск склад делал крюк через Питер, вот и попросил tracert

(17) чет казалось, что умные люди уже лет 10 такое и делают в таких случаях, а не это все.

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

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

(24) не надо ждать, ставь пингование с выводом результата в текстовик, утром проанализируешь.
после 6-7 вечера приходят домой, начинают смотреть ролики, канал провайдера нагружается, у тебя начинаются тормоза.
Самый простой варинат: в 6 вечера у тебя выходит сторож на работу, включает ютуб, и все твои 5мбит улетают к нему

(23) На базу в полтора гига ставить SQL, ну это конечно тот еще прикол. Сколько же лишних телодвижений...

(22) Если не нужен именно чистый http (веб клиент или по соображениям сецурити, например) - ни какого выигрыша веб сервер, конечно, не даст.
Внутри доморощенного 1С RPC и так по сути http завёрнуто (что видно в ТЖ, например).
Более того ацкий алгоритм сжатия от 1С (который усиленное сжатие) через http работать не умеет.

(27) Да что вы говорите....

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

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

а вот когда по http то там все не так, клиент обращается к серверу "для меня ничего нового нет?"

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

ну и tcp пакеты через vpn это такое

(31)+ особенно если vpn "односторонний" - в смысле только с одной стороны белый ip

(20) 22ms для пакета в 5120кб норм или может быть и лучше? Прова стоит дёрнуть на предмет улучшения на этот счёт?

(29) Какой фундамент? Файловая база в 10Гб и 3000 документов в день отлично работает через веб морду.

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

(29) по всей видимости, у тебя  ошибочное мнение, что через веб-морду можно только файловую?
Нет. Скульную тоже можно через веб-сервер опубликовать.
Так что насчет фундамента можешь не беспокоится. :)

Скорость зависит от того, сколько данных будет передаваться по каналу. Но 5мб - весьма и весьма мало. Стоит кому-то влезть в интернет, получить данные по видеонаблюднию, получить запрос по какому-нибудь справочнику с ценами и остатками на стороне клиента. Тормоза могут быть очень сильными.

(36) Ну, как-бы можно и так сказать, просто при наличии поднятого скуля не совсем понимал необходимость публикации также на веб-сервере, по-итогам обсуждения получается что есть смысл поднимать параллельно и его тоже. Планирую сегодня завтра заняться этим, спасибо всем добрым людям, будем пробовать улучшить ситуацию, поскольку пров пока особо не чешется с задержками и низким пингом, по-прежнему в районе 22-23мс. на 5кб пакета, видимо считает это нормальным.
Пропинговал сервер с других точек 5кб пакетом, стабильно 7-8мс.

(37) Скорость конечно по-сегодняшним меркам черепашья, вы всё верно говорите, надо хотя бы под 20мегабит поднимать, но цена растет астрономически и провайдер монополист, только если мобильного провайдера LTE роутер ставить, но боюсь что там задержки будут еще хуже. Короче говоря в любом случае разбираться нужно с таким значением, если везде по 8мс, а здесь в 3 раза хуже.
Я так понимаю что изменение ширины канала на задержки влияния не оказывают, этот вопрос придется решать пока.

(30) >т.е. сервер 1С может дергать клиента
Это вы сами придумали или где-то вычитали?

Не считая системы взаимодействия (которая ни разу не сервер 1с) взаимодействие тонкого клиента с сервером исключительно однонаправленное.
Даже возврат с сервера сообщений (которые от Сообщить) из-за этого весьма своеобразно сделан.

(21) >ну и tcp пакеты через vpn это такое
А http 1.1 по вашему через UDP работает? ;)

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

(40) А это, детектив, правильный вопрос (с)

(40) подучи теорию
прежде чем пытаться

(42)+ https://habr.com/ru/articles/564772/

(39) второй год уже пользуемся LTE мегафоном с отдельной внутренней антенной. Скорость 50-60, задержку не немного, но совсем небольшая. Видео ни кто не гоняет, особо файлы не гоняем, 1С база удаленно по RDP. RDP работает очень хорошо.  Лишь иногда раз-два в месяц бывают на 5-10 минут косяки у мегафона.

(44) Ключевое слово у тебя - по RDP.
Если бы у автора был RDP, то и вопроса бы в сабже не возникло. Потому что канал на 5 мегабит для RDP - хватит за глаза.

Кстати, любопытно, что автор RPD  даже не рассматривает.

(45) кассовое оборудование утомительно в RDP закидывать и держать онлайн постоянно.

(46) Незнаю, у нас в банке был канал 512Кб для программы по приему коммуналки с Новосибирском, кассы работали отлично.

(42) Мне было очень интересно мнение очередного гения с мисты, который в качестве пруфов своей высосанной из пальца теории приводит рандомные статьи с хабра ;)

Да, я понимаю что сам ещё больше анонимус и пруфов ни каких не приведу (с другой стороны доказывать что http 1.1 работает поверх tcp у меня как-то и желания нет...) - ну значит так. Разработчикам платформы своё мнение, гениям с мисты - своё ;)

(48) протокол http не вызывает клиента с сервера

(45) Ну, как бы изначально с интернетом на объектах складывалось хорошо и по-цене и по-ширине канала, стабильная связь, канал сотка, пол-сотни за небольшие деньги, Циска везде под телефонию внутреннюю пашет уже много лет, тунели GRE железобетонные, простые как две копейки в настройке и мониторинге, не помню чтобы как-то подводили. Подняли сервер на всём этом, всё более чем устраивало, не видели смысла и причин заморачиваться еще с RDP, тратить ресурсы машинки на это, и как было сказано определенной гемор с подключаемым оборудованием в магазинах, какое никакое есть ридеры, кассы, принтеры этикеток, эквайринг. Поэтому получилось как получилось, может и не совсем грамотно и правильно, но работает, пока вот не столкнулись с новым провайдером и его зверскими ценами.
p.s. Провайдер для теста выделил другой айпишник, на сотке, как утверждает физику оставил ту же, короче говоря видит решение в повышение ширины канала, конечно ежу понятно что это в его интересах, якобы на 5 мегабитном пинги улучшить не получится, надо поднимать тариф. Думаю бред, но такая ситуация, наверное буду пробовать с мобильным провайдером, LTE, посмотрим, всем большое спасибо за участие!