Почему 1С тормозит при работе через RDP только в одном удаленном офисе?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В практике администрирования «1С:Предприятия» часто встречается ситуация: все пользователи работают в единой клиент-серверной базе на терминальном сервере, у большинства сотрудников система работает быстро, но на одной конкретной торговой точке или в удаленном филиале наблюдаются сильные задержки. Разберем по шагам, как локализовать источник проблемы, отличить сетевые задержки интерфейса RDP от зависаний самой платформы 1С и какие меры предпринять для устранения неполадок.

Диагностика: разграничение сетевых задержек RDP и производительности 1С

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

  1. Задержка терминальной сессии (RDP Lag): курсор мыши перемещается рывками, вводимый с клавиатуры текст появляется с опозданием, окна перерисовываются медленно, картинка «залипает». При этом сам сервер выполняет операции мгновенно, но обновленные кадры экрана не успевают вовремя дойти до клиента.
  2. Замедление на стороне 1С и СУБД: интерфейс RDP отзывчив (меню «Пуск» и стандартные приложения открываются мгновенно), но внутри «1С:Предприятия» долго проводятся документы, зависает динамический список номенклатуры, появляются блокировки транзакций или долго формируются отчеты.

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

Шаг 1. Проверка сетевого канала, задержек и стабильности

Проверим время отклика (RTT) и наличие потерь пакетов на проблемном узле. Высокий пинг (более 100–150 мс) и нестабильные скачки (например, 57 мс, затем 322 мс) напрямую указывают на проблему канала связи (джиттер и потери пакетов).

  1. Запустим расширенную проверку пинга с проверкой фрагментации: ping <IP_сервера> -n 100 -l 1400 -f
  2. Проанализируем промежуточные маршруты и узлы с высокими задержками:
    
    tracert <IP_сервера>
    pathping <IP_сервера>
    

Если наблюдаются потери даже в 1–2% пакетов, протокол RDP поверх TCP начинает лавинообразно запрашивать повторную передачу данных, из-за чего экранный буфер полностью замирает. В этом случае корень проблемы лежит на физическом или канальном уровне интернет-провайдера удаленного офиса.

Шаг 2. Оптимизация параметров подключения RDP

Если физически улучшить интернет-канал невозможно, оптимизируем профиль подключения клиента (.rdp-файл) и серверные политики:

  1. Отключение визуальных эффектов: в свойствах RDP-подключения на вкладке «Взаимодействие» (Experience) выберем профиль «Низкоскоростное широкополосное подключение» (Low-speed broadband). Это отключит сглаживание шрифтов ClearType, темы оформления, анимацию меню и отображение содержимого окна при перетаскивании.
  2. Включение кэширования графики: убедимся, что включена опция постоянного кэширования точечных рисунков (Bitmap Caching).
  3. Отключение неиспользуемых ресурсов: на вкладке «Локальные ресурсы» отключим воспроизведение звука, проброс локальных жестких дисков и буфера обмена, если они не требуются для работы.
  4. Включение протокола UDP: проверим, разрешен ли на сетевом оборудовании порт 3389/UDP. Современный RDP при работе по UDP значительно лучше переносит потери пакетов и обеспечивает более плавную картинку по сравнению со строгим TCP.

Шаг 3. Влияние перенаправления принтеров и оборудования

Одной из скрытых причин зависания форм в 1С при работе по RDP является автоматический проброс локальных принтеров через Easy Print или драйверы производителя. При открытии форм документов, списков или отчетов платформа 1С выполняет опрос установленного по умолчанию принтера. На медленном канале синхронный опрос удаленного драйвера приводит к «замиранию» интерфейса 1С на 3–10 секунд.

  1. Отключим перенаправление принтеров в свойствах RDP-клиента.
  2. Настроим прямую сетевую печать через локальный принт-сервер или по протоколу TCP/IP (порт 9100 / LPR) без использования виртуальных сессионных каналов RDP.

Шаг 4. Проверка прав доступа, RLS и кэша пользователя

Если сеть в порядке, но под конкретными учетными записями удаленного подразделения 1С работает медленно, проанализируем параметры конфигурации и профиля:

  1. Проверка прав и RLS: если для удаленной точки действует ограничение прав на уровне записей (например, видимость только своего склада или организации), SQL-запросы платформы усложняются дополнительными соединениями таблиц, что замедляет открытие списков. Проверим скорость работы под учетной записью с полными правами.
  2. Очистка кэша 1С: очистим локальный кэш пользователя на терминальном сервере в каталогах AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8.

Альтернативное решение: публикация базы и переход на Тонкий клиент

Если удаленная точка подключена через нестабильный канал с высоким пингом, наиболее эффективным архитектурным решением является отказ от RDP в пользу Тонкого клиента «1С:Предприятия»:

  1. Опубликуем информационную базу на веб-сервере (IIS или Apache) по протоколу HTTPS.
  2. Установим платформу 1С локально на рабочие станции удаленного офиса.
  3. В свойствах подключения информационной базы укажем веб-адрес публикации и включим опцию «Использовать режим низкой скорости соединения».

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

← На главную