В процессе разработки и оптимизации высоконагруженных систем на платформе «1С:Предприятие 8» программисты часто сталкиваются с неочевидным поведением производительности. Одним из таких парадоксов является разница в скорости выполнения серверных вызовов из-под различных клиентских приложений. Проведем детальный анализ ситуации, когда 1000 последовательных «пустых» серверных вызовов выполняются на тонком клиенте почти в два раза быстрее, чем на толстом клиенте в режиме обычного приложения.
Разберем по шагам технические причины этого явления, проанализируем влияние сетевой инфраструктуры и протоколов отладки, а также выработаем практические рекомендации по снижению задержек (latency) при клиент-серверном взаимодействии.
Для понимания масштаба проблемы рассмотрим классический тест производительности. На стороне клиента в цикле выполняется 1000 обращений к экспортной функции серверного общего модуля. Функция не делает никаких запросов к базе данных SQL и просто возвращает пустую строку:
Функция ПолучитьПустуюСтрокуСервера() Экспорт
Возврат "";
КонецФункции
При замере времени выполнения этого цикла на одной и той же аппаратной конфигурации (сервер приложений и СУБД находятся на мощном сервере, клиент — на рабочей станции, объединенной гигабитной сетью) получаются следующие результаты:
На первый взгляд результат кажется парадоксальным. Толстый клиент исторически считается более «мощным» и функциональным. Почему же накладные расходы на простейший вызов в нем оказываются значительно выше? Выясним истинные причины этой архитектурной особенности платформы 1С.
Проанализируем наиболее частую ошибку при проведении подобных тестов. Как справедливо отмечено в обсуждении, замеры, проводимые внутри сеанса, запущенного из Конфигуратора (в режиме отладки), будут кардинально отличаться от работы системы в реальных условиях.
В платформе «1С:Предприятие 8.3» по умолчанию используется HTTP-протокол отладки. Когда клиентское приложение запущено под отладчиком:
dbgs).1cv8.exe) синхронизация состояния с отладочным сервером занимает гораздо больше времени, чем у легковесного тонкого клиента (процесс 1cv8c.exe).Если запустить тесты на клиентах без использования режима отладки (и тем более с отключенной отладкой на самом сервере приложений 1С с помощью ключа запуска службы без параметра -debug), разница в чистом времени отклика между клиентами существенно сократится, а общее время выполнения теста упадет в разы.
Сравним физический «вес» исполняемых файлов клиентских приложений:
1cv8.exe): это огромный монолитный процесс. Он несет в себе компилятор встроенного языка, рантайм-библиотеки для работы с локальными файловыми СУБД, движок отрисовки интерфейса обычных форм, подсистемы интеграции через COM/ActiveX и многое другое.1cv8c.exe): это максимально облегченная среда. Ее основная задача — отрисовка интерфейса управляемых форм на основе XML-описаний, полученных от сервера, и передача пакетов данных.С точки зрения операционной системы Windows, планировщик процессора тратит значительно больше ресурсов на обслуживание потоков тяжелого процесса 1cv8.exe. Контекстное переключение (Context Switch) при обработке сетевых сокетов, получении пакета ответа от сервера приложений 1С и передаче его обратно интерпретатору встроенного языка в толстом клиенте занимает микроскопически больше времени. При единичном вызове эта разница неощутима, но при циклическом повторении операции 1000 раз задержки суммируются в секунды.
При вызове серверного метода платформа выполняет сериализацию переданных параметров, а при возврате значения — десериализацию результата на стороне клиента. Тонкий клиент изначально проектировался под веб-стандарты и работу по относительно медленным каналам связи. Форматы передачи данных для управляемого приложения (XDTO, оптимизированные бинарные потоки) максимально сжаты и адаптированы для быстрой обработки.
В толстом клиенте (особенно в обычном приложении) для сохранения обратной совместимости со старыми конфигурациями и COM-компонентами могут использоваться более тяжелые механизмы сериализации. Платформа передает избыточный служебный контекст (например, состояние глобального модуля, информацию о транзакциях и COM-соединениях), что увеличивает объем пересылаемых по сети байтов и нагрузку на процессоры клиента и сервера при их разборе.
При выполнении множества последовательных микро-запросов (когда объем полезных данных равен нулю, как в случае с пустой строкой) ключевым фактором становится не пропускная способность сети (1 Гбит/с), а задержка доставки пакета (Round Trip Time, RTT).
По умолчанию в сетевом стеке операционных систем семейства Windows включен алгоритм Нагла. Этот алгоритм предназначен для уменьшения количества мелких пакетов в сети: он задерживает отправку маленького TCP-пакета до тех пор, пока от получателя не придет подтверждение приема предыдущего пакета или пока не накопится достаточный объем данных для отправки. При частых синхронных вызовах это может приводить к искусственным задержкам до 200 мс на каждый физический пакет.
Поведение сетевых сокетов для процессов 1cv8.exe и 1cv8c.exe может отличаться из-за внутренних настроек сетевых библиотек, используемых платформой, что также накладывает свой отпечаток на итоговую скорость.
---
Рассмотрим комплекс мер, направленных на минимизацию времени реакции сервера и оптимизацию клиент-серверного взаимодействия в вашей конфигурации.
Самый эффективный способ борьбы с задержками — это сокращение количества обращений к серверу. Сетевые накладные расходы платформы на организацию вызова всегда будут узким горлышком. Вместо того чтобы вызывать сервер в цикле 1000 раз, необходимо собрать все параметры в коллекцию (например, массив или структуру) и передать их на сервер за один вызов.
Посмотрим на пример неоптимального кода:
// НЕОПТИМАЛЬНО: 1000 обращений к серверу по сети
Для Каждого СтрокаТовара Из ТаблицаТоваров Цикл
Цена = ПолучитьЦенуНаСервере(СтрокаТовара.Номенклатура);
СтрокаТовара.Цена = Цена;
КонецЦикла;
Перепишем этот алгоритм с использованием пакетирования данных:
// ОПТИМАЛЬНО: 1 обращение к серверу по сети
МассивНоменклатуры = ТаблицаТоваров.ВыгрузитьКолонку("Номенклатура");
СоответствиеЦен = ПолучитьТаблицуЦенНаСервере(МассивНоменклатуры);
Для Каждого СтрокаТовара Из ТаблицаТоваров Цикл
СтрокаТовара.Price = СоответствиеЦен.Получить(СтрокаТовара.Номенклатура);
КонецЦикла;
Один серверный вызов, длящийся 100 миллисекунд, всегда отработает быстрее и потребует меньше ресурсов процессора, чем 1000 вызовов по 2 миллисекунды.
Если вы работаете в управляемом приложении (Тонкий клиент), при объявлении процедур и функций в модуле формы обязательно используйте директиву компиляции &НаСервереБезКонтекста вместо обычного &НаСервере.
&НаСервереБезКонтекста
Функция ПолучитьДанныеБезКонтекста(Параметр)
// Данный вызов не передает данные формы (реквизиты, элементы управления) на сервер.
// Сетевой трафик минимален.
Возврат Справочники.Номенклатура.НайтиПоРеквизиту("Артикул", Параметр);
КонецФункции
При контекстном вызове (&НаСервере) платформа сериализует состояние всей формы и передает его на сервер приложений, а затем возвращает измененный контекст обратно на клиент. При наличии тяжелых табличных частей на форме это вызывает колоссальные задержки.
Для минимизации аппаратных сетевых задержек в локальной сети рекомендуется выполнить тонкую настройку сетевых карт на рабочих станциях пользователей и сервере приложений 1С:
Тяжелый процесс толстого клиента 1cv8.exe часто вызывает повышенный интерес со стороны систем проактивной защиты и антивирусного ПО. Антивирус может перехватывать и анализировать каждый сетевой сокет, открываемый процессом, что приводит к значительным задержкам при серийных вызовах.
Добавьте следующие исполняемые файлы в список исключений вашего антивируса на клиентских машинах и на сервере приложений:
1cv8.exe (Толстый клиент)1cv8c.exe (Тонкий клиент)rphost.exe (Рабочий процесс сервера 1С)Также рекомендуется внести в исключения сканирования каталоги временных файлов пользователей (%TEMP%), куда платформа активно кэширует конфигурацию и метаданные при запуске и работе.