Ситуация, когда после замены сетевого оборудования или перенастройки веб-сервера IIS конкретные отчеты (например, ОСВ по 41 счету) начинают работать значительно медленнее, является довольно распространенной. Особенно часто это проявляется в файловых базах 1С:Бухгалтерия 3.0, развернутых на настольных операционных системах типа Windows 10. Рассмотрим подробно причины возникновения таких «тормозов» и разберем по шагам методы их устранения.
Первым делом проанализируем ситуацию: если на самом компьютере, выполняющем роль сервера, отчет формируется мгновенно (даже через браузер по локальному адресу), а при удаленном подключении возникают задержки в 2–3 минуты, проблема локализована в канале передачи данных или в настройках обработки сетевого трафика веб-сервером IIS.
Важно понимать разницу между отчетами. Например, ОСВ по 62 счету («Расчеты с покупателями») обычно содержит меньше записей и аналитик, чем ОСВ по 41 счету («Товары»). В 41 счете задействовано субконто «Номенклатура», «Склады» и часто «Партии». Это генерирует огромный объем данных в формате XML или JSON, который должен быть передан от сервера к тонкому клиенту или браузеру. Если небольшие пакеты данных (как для 62 счета) проходят быстро, а большие пакеты (для 41 счета) вызывают задержку, мы имеем дело с сетевыми ограничениями.
Для того чтобы точно выяснить, на что тратится время — на выполнение запроса к базе данных или на передачу ответа пользователю, необходимо настроить технологический журнал (ТЖ) на стороне сервера. Проанализируем пример настройки файла logcfg.xml для сбора данных о длительных операциях:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\WEB" history="2">
<event>
<eq property="Name" value="W3WP"/>
<gt property="Duration" value="1000000"/>
</event>
<property name="All"/>
</log>
</config>
Посмотрим на полученные логи. Если событие формирования отчета в ТЖ занимает доли секунды, а пользователь видит результат через 3 минуты — проблема в сетевой передаче. Если же и в ТЖ время выполнения велико — проблема в ресурсах сервера или блокировках IIS.
Поскольку проблема возникла после смены роутера, одним из наиболее вероятных виновников является параметр MTU (Maximum Transmission Unit). Это максимальный размер пакета, который может быть передан по сети без фрагментации.
Разберем ситуацию: стандартное значение MTU — 1500 байт. Однако многие провайдеры (особенно при использовании PPPoE или VPN-туннелей) требуют меньшего значения (например, 1492 или 1450). Если роутер получает пакет большего размера, он начинает его дробить (фрагментировать), что при передаче тяжелых отчетов 1С приводит к колоссальным задержкам или потере пакетов.
Выясним оптимальный размер MTU с помощью команды ping в консоли Windows:
ping [адрес_сервера] -f -l 1472
Если команда выдает «Требуется фрагментация пакета», постепенно уменьшайте значение 1472, пока пакет не пройдет успешно. Найденное значение (плюс 28 байт заголовка) и будет вашим идеальным MTU, которое нужно прописать в настройках WAN-порта роутера или в свойствах сетевого адаптера сервера.
При работе через веб-сервер объем передаваемых данных критичен. Выясним, включено ли динамическое сжатие в IIS. По умолчанию в Windows 10 компоненты IIS могут быть установлены без модуля Dynamic Content Compression.
Службы IIS -> Общие функции HTTP.IIS на уровне сервера или конкретного сайта зайдем в раздел «Сжатие» и включим оба параметра.Это позволит серверу сжимать данные ОСВ по 41 счету перед отправкой, уменьшая объем трафика в 5–10 раз, что критично для удаленных пользователей.
Проанализируем программные ограничения. Windows 10 Pro не является полноценной серверной ОС. В ней существует жесткий лимит на количество одновременных сетевых соединений (обычно до 20).
Даже если в базе работают всего два человека, каждый сеанс 1С (особенно через браузер) открывает множество соединений для загрузки скриптов, картинок и данных. При формировании тяжелого отчета количество запросов может временно превысить лимит, и IIS начнет ставить новые запросы в очередь.
Для минимизации этой проблемы проверим настройки пула приложений:
Разрешить 32-разрядные приложения установлено в True, если используется 32-битная платформа 1С.Режим управления очередью.Тайм-аут простоя (минуты) в значение 0, чтобы процесс w3wp.exe не засыпал.Еще один важный параметр — HTTP Keep-Alive. Эта опция позволяет браузеру или тонкому клиенту использовать одно и то же TCP-соединение для нескольких запросов. Если она выключена, то для каждого субконто или строки отчета может инициироваться новое соединение, что крайне медленно на удаленных каналах с высокими задержками (ping).
Проверим это в разделе «Заголовки ответов HTTP» в IIS. Убедимся, что флаг «Включить Keep-Alive» установлен.
Рассмотрим влияние протокола IPv6. Часто новые роутеры пытаются приоритезировать IPv6-трафик. Если в локальной сети или на сервере IPv6 настроен некорректно, система может сначала пытаться отправить запрос по IPv6, ждать таймаута и только потом переходить на IPv4. Это может добавлять те самые секунды задержки к каждому запросу данных отчета.
Рекомендуется полностью отключить протокол IPv6 в свойствах сетевого адаптера на компьютере, где установлен IIS. Также стоит временно удалить (а не просто отключить) сторонние антивирусы с модулями веб-защиты, так как их сетевые драйверы продолжают фильтровать трафик IIS даже в «выключенном» состоянии, что на больших объемах текста (ОСВ) вызывает тормоза.
Для решения проблемы долгого формирования ОСВ по 41 счету через IIS мы рекомендуем придерживаться следующего алгоритма:
localhost) и удаленно.IIS.Выполнение этих шагов в большинстве случаев позволяет вернуть скорость работы удаленных пользователей к комфортным значениям, сопоставимым с работой в локальной сети.