Тонкий клиент 1С на слабом канале: что реально ускоряет работу филиала

Филиал жалуется, что 1С работает медленно. Провайдер меняет тариф со 100 на 300 Мбит — ничего не меняется. Такой сценарий мы видели десятки раз, и он закономерен: тонкий клиент упирается не в ширину канала, а в задержку. Разберём, как это устроено, что можно измерить за десять минут и какие решения реально помогают, а какие только тратят бюджет.

Тонкий клиент не тянет данные целиком — он общается с сервером короткими запросами. Открыл список — запрос. Прокрутил — запрос. Раскрыл документ — несколько запросов.

Каждый такой обмен требует полного оборота пакета до сервера и обратно. Это и есть round-trip.

Дальше арифметика. Пусть открытие формы документа требует 25 обращений к серверу. При задержке 1 мс это 25 мс — незаметно. При задержке 60 мс это уже полторы секунды только на сетевые задержки, безотносительно того, насколько быстр сервер.

Ширина канала в этой арифметике почти не участвует. Объём одного обмена — единицы килобайт, и он передаётся за микросекунды хоть на 100 Мбит, хоть на гигабите.

Отсюда главный практический вывод, который нам приходится объяснять почти каждому клиенту с филиалом: увеличение скорости канала не ускоряет 1С. Помогает уменьшение задержки — а его тарифом не купишь.

Три измерения, которые дают полную картину.

Задержка и её стабильность. Не среднее, а разброс:

Test-Connection srv-1c.corp.local -Count 200 |
  Measure-Object ResponseTime -Average -Minimum -Maximum |
  Format-List
# и посмотреть распределение
(Test-Connection srv-1c.corp.local -Count 200).ResponseTime |
  Group-Object | Sort-Object Name | Select-Object Name, Count

Потери пакетов. Даже 1 % потерь бьёт по отзывчивости сильнее, чем рост задержки на 20 мс: потерянный пакет означает ожидание повторной передачи по таймауту TCP.

Трассировка. Показывает, где именно набирается задержка — у провайдера филиала, в магистрали или уже в вашей сети.

tracert -d srv-1c.corp.local
# или подробнее, с накоплением статистики по хопам
pathping -q 50 srv-1c.corp.local

Ориентиры для оценки результата:

Замер делайте в рабочее время, а не вечером. Задержка на перегруженном канале днём и ночью различается кратно.

Прежде чем менять архитектуру, стоит проверить очевидное. Иногда задержка искусственная.

• Маршрут через VPN-концентратор в другом городе. Частая находка: филиал в Твери, сервер в Москве, но трафик идёт через VPN-шлюз, физически стоящий в Екатеринбурге. Плюс 60 мс на ровном месте.
• Двойное туннелирование. VPN внутри VPN добавляет и задержку, и накладные расходы на инкапсуляцию.
• Неправильный MTU. Фрагментация пакетов на туннеле увеличивает эффективную задержку и даёт потери. Проверяется подбором размера пакета без фрагментации.
• Wi-Fi на рабочих местах. Добавляет 5–30 мс и переменность.
• Перегруженный канал. Если сотрудники филиала смотрят видео, 1С стоит в общей очереди. Приоритизация трафика решает это лучше расширения полосы.

ping -f -l 1472 srv-1c.corp.local
# уменьшать 1472 до исчезновения "Требуется фрагментация пакета"

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

Кое-что регулируется и на уровне платформы.

Подключение по HTTP вместо протокола кластера. Тонкий клиент умеет работать через веб-публикацию. Это не только удобнее с точки зрения проброса портов — HTTP-канал лучше переживает нестабильность и не требует прямой видимости кластера.

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

Не чистить кэш «на всякий случай». Распространённая вредная привычка: при любой жалобе удалять каталог кэша. На хорошем канале цена этого — секунды, на слабом — несколько минут ожидания при следующем входе.

Низкая скорость соединения. В свойствах базы в списке есть галка о низкой скорости соединения. Она включает более агрессивное кэширование и сокращает число обращений к серверу. На канале с задержкой выше 30 мс даёт заметный эффект. На быстром канале — наоборот, может слегка замедлить.

Проверить стоит эмпирически: включить у одного пользователя, замерить те же операции, сравнить.

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

Идея терминального доступа в контексте нашей задачи проста: перенести клиента 1С физически ближе к серверу. Тогда все двадцать пять round-trip на открытие формы происходят внутри дата-центра за доли миллисекунды, а по слабому каналу передаётся только изображение экрана.

Протокол RDP к задержке гораздо терпимее: он передаёт дельту картинки и умеет работать поверх UDP с компенсацией потерь. Комфортная работа сохраняется при RTT 100–150 мс, где прямое подключение 1С уже невозможно.

Наш ориентир для принятия решения:

Цена вопроса: терминальный сервер — это лицензии RDS, ресурсы и администрирование. Но по опыту он окупается уже на пяти-семи пользователях филиала, если считать не стоимость железа, а стоимость времени людей.

Полезно перевести абстрактную «задержку» в минуты рабочего времени — тогда разговор про бюджет становится предметным.

Возьмём реальные числа с наших замеров. Открытие формы списка документов в УТ порождает в среднем 18–30 обращений к серверу, открытие формы документа — 20–40, проведение реализации с двадцатью строками — от 60 до 120 в зависимости от настроек учёта и количества подключённых подсистем, потому что каждое движение по регистру, каждая проверка заполнения и каждое обращение к механизму дополнительных реквизитов добавляют свои обмены.

Возьмём среднее — 40 обращений на значимое действие.

При задержке 10 мс сетевая составляющая одного действия — 0,4 секунды. При 50 мс — 2 секунды. При 94 мс, как в кейсе ниже, — почти 4 секунды. И это только сеть, без учёта работы сервера и СУБД.

Теперь умножаем на объём работы. Менеджер филиала выполняет за день около 150 значимых действий в программе. Разница между каналом с задержкой 10 мс и 94 мс составляет для него примерно 3,6 секунды на действие, то есть девять минут в день чистого ожидания.

Четырнадцать человек филиала — это два часа рабочего времени в день, выброшенных в никуда. Порядка сорока часов в месяц.

Эта арифметика — лучший аргумент в разговоре с руководителем, потому что она не про технологии. Она про то, сколько стоит не сделать ничего, и обычно оказывается, что стоимость бездействия выше стоимости решения в разы.

Список решений, которые предлагают часто и которые в этой задаче не работают.

Увеличивать скорость канала. Уже разобрали. Помогает, только если канал реально забит; если задержка высока при свободном канале — не даст ничего.

Ставить локальную копию базы в филиале с обменом. Кажется логичным, но создаёт распределённую систему с конфликтами данных, отложенной синхронизацией и удвоенной стоимостью поддержки. Оправдано только при полной автономии филиала по бизнес-процессам, а не для ускорения.

Переводить филиал на файловый вариант базы по сети. Худший из возможных вариантов. Файловая база по WAN — это не медленно, это неработоспособно и опасно для целостности данных.

Апгрейдить сервер. Если проблема в задержке канала, сервер может быть сколь угодно быстрым — round-trip от этого не сократится.

Менять рабочие станции в филиале. Тонкий клиент нетребователен к железу. Если станция не совсем древняя, замена ничего не изменит.

Общее правило: сначала измерьте задержку и потери, потом принимайте решение. Половина бюджетов, потраченных на «ускорение 1С в филиале», уходит на решения, не связанные с реальной причиной.

Клиент — производственная компания с площадкой в области, 14 рабочих мест в филиале, база УТ в московском дата-центре.

История до нас: филиал жаловался полтора года. Провайдера меняли дважды, тариф подняли с 50 до 200 Мбит, в филиале поставили новый маршрутизатор и заменили восемь компьютеров. Эффекта не было ни от чего.

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

Средний RTT до сервера — 94 мс. Потери — 0,2 %. Канал при этом загружен на 6 %.

Трассировка объяснила всё. Трафик от филиала шёл в Москву не напрямую, а через VPN-концентратор, который при построении сети три года назад разместили на площадке в Новосибирске — тогда там был головной офис. Офис давно переехал, концентратор остался.

Физически пакет из подмосковного филиала ехал в Новосибирск и возвращался в Москву. Четыре тысячи лишних километров в каждую сторону.

Решение заняло один вечер: подняли туннель напрямую до московской площадки, перенастроили маршрутизацию, старый концентратор оставили резервным.

RTT стал 11 мс. Открытие списка документов ушло с 6,8 секунды до 0,9. Проведение реализации — с 12 секунд до 2,4.

Полтора года жалоб и три бюджета — на проблему, которая диагностировалась одной командой tracert. Мне этот случай нравится тем, что он идеально иллюстрирует общий принцип: без замера любое решение — это ставка, и большинство ставок проигрывает.

Почему увеличение скорости канала не ускорило 1С?

Тонкий клиент обменивается с сервером множеством коротких запросов, и время работы определяется задержкой на каждый оборот пакета, а не пропускной способностью. Объём одного обмена — единицы килобайт, он передаётся мгновенно и на 50 Мбит, и на гигабите.

Какая задержка допустима для прямого подключения тонкого клиента?

До 20 мс работа комфортна, 20–50 мс — терпима при приоритизации трафика и включённом режиме низкой скорости соединения, выше 50 мс прямое подключение лучше заменить терминальным доступом.

Что даёт галка «низкая скорость соединения» в списке баз?

Более агрессивное кэширование на клиенте и меньше обращений к серверу. На канале с задержкой выше 30 мс эффект заметный, на быстром канале может слегка замедлить работу — проверяйте замером на одном пользователе.

Стоит ли ставить в филиале отдельную базу с обменом?

Только если филиал автономен по бизнес-процессам. Ради ускорения — нет: вы получите распределённую систему с конфликтами данных, отложенной синхронизацией и вдвое более дорогой поддержкой. Терминальный доступ решает задачу скорости проще.