Как проверить конфигурацию 1С на медленном канале связи
Содержание
Имитация задержки при вызовах сервера в 1С 8.3 включается в Конфигураторе: Сервис → Параметры → Запуск 1С:Предприятия → Дополнительно, флажок «Имитация задержки при вызовах сервера». После этого клиент, запущенный из Конфигуратора, ждёт заданное время на каждом обращении к серверу и на каждом килобайте переданных данных. Так разработчик видит, как форма поведёт себя у пользователя на медленном канале.
Способов замедлить систему три, и они решают разные задачи. Флажок платформы — самый быстрый: он показывает лишние серверные вызовы в коде форм. Пауза в коде нужна, чтобы воспроизвести долгую операцию и проверить блокировки. Сетевая эмуляция (netem, прокси) ближе всего к реальности: она замедляет весь трафик, включая установку соединения.
Зачем разработчику 1С специально замедлять систему
В локальной сети ответ сервера приходит за единицы миллисекунд. Форма, которая делает 40 серверных вызовов при открытии, открывается мгновенно, и ошибку проектирования никто не замечает. У пользователя в филиале, на мобильном интернете или через VPN каждый вызов стоит 100–300 мс. Те же 40 вызовов превращаются в 4–12 секунд ожидания.
Что выявляет искусственная задержка:
- 🔁 серверные вызовы в цикле на клиенте — например, получение реквизита ссылки для каждой строки табличной части;
- 📦 передачу лишних данных — полной формы туда и обратно вместо
&НаСервереБезКонтекста; - ⏳ обработчики
ПриИзменении, которые ходят на сервер при каждом нажатии клавиши; - 🔒 места, где долгая транзакция держит блокировку и другие пользователи ждут;
- 🧩 ошибки асинхронного кода — когда пользователь успевает нажать кнопку второй раз, пока первый вызов не вернулся.
Этот режим полезен при разработке под тонкий клиент, веб-клиент и мобильный клиент. Для толстого клиента в режиме обычного приложения он мало что даёт: там большая часть логики и так работает на клиенте.
Встроенная эмуляция задержки в платформе 1С
Флажок живёт в параметрах Конфигуратора и действует только на сеанс, который вы запускаете кнопкой Отладка → Начать отладку (или F5). Обычные пользователи его не получают, база не меняется.
Как включить
- Откройте Конфигуратор нужной базы.
- Перейдите в
Сервис → Параметры, вкладка «Запуск 1С:Предприятия». - На вложенной вкладке «Дополнительно» установите флажок «Имитация задержки при вызовах сервера».
- Задайте три значения задержки (о них ниже) и нажмите «ОК».
- Запустите отладку тонким или веб-клиентом — замедление сразу заметно.
Что означают параметры
| Параметр | Что задаёт | Значение по умолчанию |
|---|---|---|
| Задержка вызова | Пауза на каждый вызов сервера, в секундах | 1,45 |
| Задержка отправки | Пауза на каждый килобайт данных от клиента к серверу | 0,45 |
| Задержка получения | Пауза на каждый килобайт данных от сервера к клиенту | 0,15 |
Значения по умолчанию моделируют очень медленный канал уровня GPRS. Для реалистичного сценария «филиал через VPN» обычно ставят 0,1–0,3 с на вызов и 0,01–0,05 с на килобайт. Начните с умолчаний: если форма терпима даже на них, на нормальном канале проблем не будет.
Пример расчёта. Форма при открытии делает 6 вызовов и получает 120 КБ данных. При умолчаниях ожидание составит 6 × 1,45 + 120 × 0,15 = 8,7 + 18 = 26,7 секунды. Если сократить вызовы до двух и данные до 40 КБ, выйдет 2 × 1,45 + 40 × 0,15 = 2,9 + 6 = 8,9 секунды. Разница втрое видна сразу, без профилировщика.
Запуск с параметром командной строки
Тот же режим можно включить без Конфигуратора — ключом запуска клиента /SimulateServerCallDelay. К нему через дефис добавляют -Call, -Send и -Receive со значениями. Это удобно для автотестов (Vanessa Automation, сценарное тестирование): тесты гоняют под задержкой и сравнивают время шагов.
"C:\Program Files\1cv8\8.3.25.1374\bin\1cv8c.exe" /S"srv1c\buh_test" /N"Тест" /SimulateServerCallDelay -Call1450 -Send450 -Receive150
Точный синтаксис ключей для своей версии платформы сверьте в справке по параметрам командной строки (1cv8.exe /? или раздел справки «Параметры командной строки»). Номер платформы в пути замените на свой.
Пауза в коде 1С: как воспроизвести долгую операцию
Встроенного оператора «Спать» во встроенном языке нет. Паузу делают обходными приёмами, и у каждого своя цена.
Цикл ожидания по времени
Самый простой вариант — крутить цикл, пока не пройдёт нужное число миллисекунд. Работает и на клиенте, и на сервере.
&НаСервере
Процедура ПаузаНаСервере(Миллисекунды)
Конец = ТекущаяУниверсальнаяДатаВМиллисекундах() + Миллисекунды;
Пока ТекущаяУниверсальнаяДатаВМиллисекундах() < Конец Цикл
// намеренно пустой цикл
КонецЦикла;
КонецПроцедуры
Минус очевиден: цикл грузит ядро процессора на 100% всё время ожидания. На тестовом стенде это терпимо. На рабочем сервере такой код недопустим: при 20 одновременных вызовах вы съедите все ядра рабочего процесса.
Пауза через внешнюю команду
Второй приём — запустить системную команду и дождаться её завершения. Процессор не нагружается.
&НаСервере
Процедура ПаузаЧерезОС(Секунды)
// Windows: ping отправляет запрос раз в секунду, поэтому N+1 пакет ≈ N секунд
КомандаWindows = СтрШаблон("ping -n %1 127.0.0.1", Формат(Секунды + 1, "ЧГ=0"));
ЗапуститьПриложение(КомандаWindows, , Истина);
КонецПроцедуры
На сервере под Linux вместо ping используют sleep 5. Учтите: в безопасном режиме (внешние обработки без разрешения, расширения в безопасном режиме) запуск внешних программ запрещён, и код упадёт с ошибкой.
Где ставить паузу
- ⏱ Внутри транзакции перед
ЗафиксироватьТранзакцию()— проверить, как поведут себя другие сеансы, которые ждут ту же блокировку. - 📨 В обработчике HTTP-сервиса — проверить таймауты внешней системы, которая к вам обращается.
- 🔄 В фоновом задании — убедиться, что форма с индикатором длительной операции не зависает и корректно опрашивает состояние.
Паузы в коде — только в тестовой базе или в расширении, которое подключено лишь на стенде. Забытая пауза в общем модуле, попавшая в рабочую базу, остановит работу всех пользователей. Отмечайте такой код комментарием и ищите его перед сдачей.
Эмуляция медленной сети и работа через прокси
Флажок платформы добавляет фиксированную паузу, а реальная сеть ведёт себя иначе: задержка «плавает», теряются пакеты, медленно устанавливается соединение. Чтобы увидеть это, замедляют саму сеть.
Linux: tc netem
На Linux-сервере или Linux-машине клиента задержку добавляют стандартной утилитой tc с дисциплиной netem:
# добавить 200 мс задержки с разбросом ±50 мс и 1% потерь
sudo tc qdisc add dev eth0 root netem delay 200ms 50ms loss 1%
# посмотреть текущие правила
tc qdisc show dev eth0
# снять эмуляцию
sudo tc qdisc del dev eth0 root
Правило действует на весь трафик интерфейса, включая SSH и обращения к СУБД. Если поставить его на рабочем сервере 1С, замедлятся все пользователи. Делайте это на тестовом стенде или на отдельной клиентской машине и сразу проверьте, что команда снятия под рукой.
Windows: утилиты-шейперы
На клиентском компьютере с Windows используют программы, которые перехватывают трафик и задерживают его: например, открытая утилита clumsy или коммерческие шейперы. Фильтр ставят по адресу сервера 1С, чтобы не замедлять остальной трафик.
Почему прокси для клиент-серверного режима неудобен
Клиент в клиент-серверном варианте сначала обращается к агенту сервера (порт 1540), затем к менеджеру кластера (1541) и к рабочим процессам. Диапазон портов рабочих процессов задаётся в свойствах рабочего сервера, по умолчанию 1560–1591. Сервер сообщает клиенту, куда подключаться, поэтому простой TCP-прокси на одном порту не перехватит весь обмен.
Проще поступить так:
- Опубликовать базу на веб-сервере (IIS или Apache).
- Подключить тонкий клиент или веб-клиент по HTTP-адресу публикации.
- Поставить между клиентом и веб-сервером HTTP-прокси с задержкой (например, Fiddler с режимом имитации медленного модема или Toxiproxy).
Так вы проверяете ровно тот сценарий, который получат удалённые пользователи, работающие через интернет .
Таймауты и параметры кластера под нагрузкой
Задержка сама по себе не ломает систему. Ломают таймауты, которые она задевает. Перед тестом выясните, какие ограничения сработают первыми.
| Где | Что ограничивает | Как проверить под задержкой |
|---|---|---|
| Параметры информационной базы | Время ожидания блокировки данных, по умолчанию 20 секунд | Пауза в транзакции дольше 20 с — второй сеанс получит ошибку блокировки |
HTTPСоединение | Параметр «Таймаут» конструктора, в секундах | Пауза в HTTP-сервисе дольше таймаута вызывающей стороны |
| Веб-сервер | Таймауты IIS или Apache на запрос | Долгий серверный вызов через публикацию |
| Свойства кластера | Перезапуск рабочих процессов, допустимый объём памяти, принудительное завершение проблемных процессов | Длительная нагрузка с паузами и объёмными данными |
Время ожидания блокировки задают в Конфигураторе: Администрирование → Параметры информационной базы, поле «Время ожидания блокировки данных». В коде для конкретного сеанса значение меняют методом УстановитьВремяОжиданияБлокировкиДанных().
Не поднимайте таймауты только ради того, чтобы тест прошёл. Если операция под реальной задержкой упирается в 20 секунд ожидания блокировки, проблема в длине транзакции, а не в настройке.
Параметры кластера (интервал перезапуска, лимиты памяти, отказоустойчивость) открываются в консоли администрирования серверов: правой кнопкой по кластеру → «Свойства». Для эксперимента с задержками их обычно не меняют — смотрят, не срабатывает ли перезапуск процесса во время долгого теста. Если нужно изменить, делайте это вне рабочего времени: перезапуск рабочего процесса обрывает сеансы пользователей на нём.
Как анализировать производительность при искусственных лагах
Задержка показывает, что форма медленная. Найти, какой именно вызов виноват, помогают инструменты платформы.
Замер производительности в отладчике
- Запустите отладку с включённой имитацией задержки.
- В Конфигураторе выберите
Отладка → Замер производительности. - Выполните в клиенте проблемное действие: открытие формы, выбор значения, запись.
- Остановите замер и отсортируйте строки по времени.
Строки с серверными процедурами и большим числом вызовов — первые кандидаты на переработку. Если процедура &НаСервере вызывается 30 раз за одно действие, это цикл с серверным вызовом внутри.
Технологический журнал
Для клиент-серверной базы включите технологический журнал. Файл logcfg.xml кладут в каталог conf установленной платформы на сервере. Минимальная настройка для разбора серверных вызовов:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="D:\techlog" history="4">
<event>
<eq property="name" value="CALL"/>
</event>
<event>
<eq property="name" value="SCALL"/>
</event>
<property name="all"/>
</log>
</config>
События CALL показывают входящие вызовы с длительностью и объёмом, SCALL — исходящие вызовы между процессами. Значение history задаёт, сколько часов хранить логи. Журнал быстро растёт, поэтому после теста удалите или переименуйте logcfg.xml.
Что исправлять в коде
- Объединяйте несколько серверных вызовов в один: соберите все данные в структуру и верните её разом.
- Переносите получение реквизитов в
&НаСервереБезКонтекста, чтобы не гонять форму целиком. - Кешируйте постоянные данные в общих модулях с повторным использованием возвращаемых значений.
- Переносите проверки из
ПриИзменениив момент записи, если они не нужны мгновенно. - Для долгих операций используйте фоновые задания и асинхронное ожидание, а не блокирующий вызов.
Чек-лист проверки устойчивости к задержкам
Пройдите по пунктам на тестовой копии базы перед выпуском доработки для удалённых пользователей.