Работа в 1С:Предприятие в территориально распределенном режиме — это всегда вызов для системного администратора. Часто возникает ситуация, когда показатели ping между офисами кажутся идеальными (2–3 мс), но реальная скорость формирования и сохранения документов (особенно в «Толстом клиенте» на базе УТ 10.3) оставляет желать лучшего. В этой статье мы подробно разберем, почему «быстрый» пинг не гарантирует быструю работу, и как оптимизировать связку 1С + VPN.
Проанализируем ситуацию: автор темы обнаружил, что сохранение PDF-файлов на сетевой диск через VPN происходит значительно медленнее, чем в локальной сети. Основная причина здесь кроется в работе протокола SMB (Server Message Block), который используется для общих папок Windows.
Протокол SMB является крайне «болтливым» (chatty). Для выполнения простой операции записи файла клиент и сервер должны обменяться множеством служебных пакетов (подтверждение открытия, запрос прав, подтверждение получения каждого блока данных). В локальной сети с задержкой менее 1 мс это незаметно. Однако, как только мы выходим в VPN с задержкой даже в 3–5 мс, суммарное время ожидания ответов (RTT) возрастает лавинообразно. Пропускная способность канала может составлять 100 Мбит/с, но из-за задержек SMB будет использовать лишь малую часть этой ширины.
Рассмотрим, как правильно проверить качество канала. Обычная команда ping отправляет пакеты размером 32 байта, что не дает представления о реальной пропускной способности. Нам нужно проверить передачу данных большого объема.
Разберем использование утилиты iperf для тестирования TCP и UDP трафика. Выполним следующие шаги:
iperf в режиме сервера на стороне 1С-сервера (Комп2).Если iperf показывает значительные падения скорости или потерю пакетов при увеличении нагрузки, проблема в VPN-туннеле или оборудовании.
Проанализируем еще один технический аспект — MTU (Maximum Transmission Unit). Стандартный размер кадра в Ethernet — 1500 байт. Однако VPN-туннель (особенно IPsec или OpenVPN) добавляет свои заголовки (от 50 до 100 байт). Если пакет 1С размером 1500 байт пытается пройти через туннель, он фрагментируется — разбивается на два. Это создает огромную нагрузку на процессоры роутеров и вдвое увеличивает количество сетевых запросов.
Посмотрим, как вычислить оптимальный MTU. Используем команду:
ping -f -l 1460 [IP_сервера]
Если получаем сообщение «Требуется фрагментация пакета», уменьшаем значение 1460 до тех пор, пока пакет не пройдет. Найденное значение (например, 1400) нужно жестко прописать в настройках сетевых интерфейсов или VPN-туннеля.
В конфигурациях типа Управление торговлей 10.3 используется «Толстый клиент». Выясним причину его медлительности в распределенных сетях. В отличие от «Тонкого клиента», где на сервер передается только краткая команда, «Толстый клиент» выкачивает огромные объемы данных для обработки на стороне пользователя. Формирование печатной формы происходит непосредственно на Комп1, при этом клиент постоянно обращается к Комп2 (SQL-серверу) за каждой порцией данных.
Рассмотрим варианты оптимизации программного кода. Если у вас есть доступ к конфигуратору, стоит перенести логику формирования тяжелых отчетов на сторону сервера. Для этого используем общие модули с флагом «Вызов сервера».
Пример структуры вызова для оптимизации (в терминах обычных форм):
// На клиенте (в форме документа)
Процедура СформироватьИПечатать()
ТабДок = ПолучитьПечатнуюФормуНаСервере(СсылкаНаДокумент);
// Теперь сохраняем локально, а не на сетевой диск!
ПутьКФайлу = "C:\Temp\Doc.pdf";
ТабДок.Записать(ПутьКФайлу, ТипФайлаТабличногоДокумента.PDF);
КонецПроцедуры
Разберем вопрос автора о переносе компонентов. Если мы разнесем Сервер 1С и SQL Server на разные физические машины (Комп1 и Комп2), общающиеся через VPN, мы получим катастрофическое падение производительности. В нормальном состоянии эти службы общаются через протокол Shared Memory.
Посмотрим на настройки Network Packet Size в SQL Server. По умолчанию он равен 4096 байт. Для передачи тяжелых печатных форм (талмудов документов) через VPN имеет смысл увеличить этот параметр до 8192 или 16384 байт. Это уменьшит количество сетевых прерываний.
Проанализируем самый эффективный вариант, предложенный в обсуждении. Вместо того чтобы гонять «тяжелый» протокол 1С через VPN-туннель между RDP-сервером и Сервером 1С, необходимо максимально их сблизить.
Правильная схема:
Подводя итог нашему анализу, выделим контрольный список действий для исправления ситуации:
TcpAckFrequency в значение 1 для немедленного подтверждения пакетов.%LOCALAPPDATA%\1C) находятся на быстром локальном SSD, а не перенаправлены на сервер через перемещаемые профили.Следуя этим шагам, мы сможем добиться стабильной работы даже в таких сложных условиях, как использование толстого клиента 1С через территориально распределенные сети.