Быстрая передача результата запроса на клиент через COM-соединение с текущей базой

31.08.16

Разработка - Запросы

Способ ускорения передачи больших объемов данных с сервера на клиент, используя COM-соединение с текущей базой. Быстрее в 3-5 раз, по сравнению с обычными методами.

Технология клиент-сервер учит избегать передачи больших объемов данных между клиентом и сервером. Предполагается, что клиент должен отправлять на сервер короткий запрос, и получать в ответ строго необходимые данные. Поэтому необходимо оговорить, что предлагаемый способ выходит за рамки данной технологии и рекомендуется к использованию, в тех случаях, когда передачи больших объемов данных с сервера на клиент избежать не удается.

При работе обычным способом, если запрос выбирает, например, пару сотен тысяч записей за пять секунд (время можно уточнить с помощью консоли запросов), то последующая сериализация, передача на клиент и десереализация, может достигать нескольких минут. Именно это составляет основные временные затраты на заполнение таблиц на формах и формирование отчетов. Рассмотрим, как будет выглядеть работа при использовании COM-соединения.

Как известно, объект "Запрос" не существует на клиенте, однако мы можем получить его COM-отбражение:

// Создаём соединение
COMConnector = Новый COMОбъект("V83.COMConnector");
Сединение = COMConnector.Connect(СтрокаСоединения);
// Получаем COM-объект "Запрос"
Запрос = Сединение.NewObject("Запрос");

Здесь "Запрос" - это COM-объект, однако с ним можно производить все теже манипуляции, что и с обычным "Запросом":

Запрос.Текст = ТекстЗапроса;
РезультатЗапроса = Запрос.Выполнить();

Выполнение последней строки происходит относительно быстро, практически также быстро, как и обычное выполнение запроса на сервере. В результате мы получаем COM-объект "РезультатЗапроса", из которого можно получить выборку. Обратите внимание, всё это проиходит на клиенте.

Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
    . . .
    // Делаем все, что нам нужно
    . . .
КонецЦикла;

Как показала практика, такой обход запроса работает гораздо быстрее, чем обход запроса на сервере с заполнением какой-нибудь коллекции и передачей этой коллекции на клиента, будь это хоть массив, хоть табличный документ. Я не стал делать замеры, так как результаты могут сильно различасться в различных условиях. В моём случае удалось достичь сокращения времени примерно в 3-5 раз. И это несмотря, что все операции производятся над COM-объектами. Я не могу точно сказать, почему так происходит. Возможно это из-за того, что используется один цикл и для извлечения данных из СУБД, и для их обработки, а не два, как в случае заполнения коллекции на сервере и передачи её на клиент (сериализацию/десереализацию можно принять за циклы). Может быть потому что сериализация/десереализация средствами системы при работе серез COM работает быстрее, чем средствами 1C при обмене сервера и клиента. А может и то, и другое

Естественно, мы можем передавать таким образом только данные примитивных типов, то есть Число, Строка, Дата и Булево. Ну а что еще нам приходится передавать на клиент, когда мы работаем обычным способом? Ссылки? Но что такое ссылка на клиенте? Так, только представление, по сути-то. Если вдруг потребуется использовать ссылку именно как ссылку, т. е. запомнить, чтобы потом передать на сервер и как-то использовать, то в этом случае мы можем оперировать строками-уникальными идентификаторами:

Ссылка = Соединение.XMLСтрока(Выборка.Ссылка);

После передачи такой строки на сервер восстановить ссылку не составит никакого труда.

В любом случае, использование COM-соединения для работы с данными на клиенте, может оказаться полезным инструментом для решения разнообразных задач. И возможно, передача результата запроса на клиент это - лишь один из примеров подобного использования.

В заключении хочу предложить в качестве примера обработку, использующую подобную методику: Общий журнал (COM). Функционал  данного журнала весьма прост, но позволяет оценить возможность работы с результатом запроса на клиенте серез COM.

COM соединение передача клиент

См. также

SALE! 20%

Infostart Toolkit: Инструменты разработчика 1С 8.3 на управляемых формах

Инструментарий разработчика Роли и права Запросы СКД Платформа 1С v8.3 Управляемые формы Запросы Система компоновки данных Конфигурации 1cv8 Платные (руб)

Набор инструментов программиста и специалиста 1С для всех конфигураций на управляемых формах. В состав входят инструменты: Консоль запросов, Консоль СКД, Консоль кода, Редактор объекта, Анализ прав доступа, Метаданные, Поиск ссылок, Сравнение объектов, Все функции, Подписки на события и др. Редактор запросов и кода с раскраской и контекстной подсказкой. Доработанный конструктор запросов тонкого клиента. Продукт хорошо оптимизирован и обладает самым широким функционалом среди всех инструментов, представленных на рынке.

13000 10400 руб.

02.09.2020    122150    670    389    

714

Для чего используют конструкцию запроса "ГДЕ ЛОЖЬ" в СКД на примере конфигурации 1С:ERP

Запросы СКД Платформа 1С v8.3 Запросы Система компоновки данных 1С:ERP Управление предприятием 2 Бесплатно (free)

В типовых конфигурациях разработчики компании 1С иногда используют в отчетах, построенных на СКД, такую конструкцию, как "ГДЕ ЛОЖЬ". Такая конструкция говорит о том, что данные в запросе не будут получены совсем. Для чего же нужен тогда запрос?

13.02.2024    5746    KawaNoNeko    23    

23

Набор-объект для СКД по тексту или запросу

Запросы СКД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Есть список полей в виде текста, или запрос - закидываем в набор СКД.

1 стартмани

31.01.2024    2000    2    Yashazz    0    

29

Запрос 1С copilot

Инструментарий разработчика Запросы Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Абонемент ($m)

Пишем на человеческом языке, что нам надо, и получаем текст запроса на языке 1С. Используются большие языковые модели (LLM GPT) от OpenAI или Яндекс на выбор.

5 стартмани

15.01.2024    6284    31    mkalimulin    25    

50

PrintWizard: поддержка представлений ЗУП в конструкторе

Инструментарий разработчика Запросы Платформа 1С v8.3 Бесплатно (free)

Одной из интересных задач, стоящих в процессе разработки, была поддержка механизма представлений в ЗУП. Но не просто возможность исполнения запросов с ними. Основная проблема была в том, чтобы с ними было удобно работать, а именно: создавать, модифицировать и отлаживать. Кратко о том, что в итоге получилось...

14.12.2023    1742    vandalsvq    7    

29

Объектная модель запроса "Схема запроса" 2

Запросы Платформа 1С v8.3 Запросы Конфигурации 1cv8 Бесплатно (free)

Далеко уже не новый тип данных "Схема запроса". Статья о том, как использовать его "попроще". Примеры создания текста запроса с нуля и изменение имеющегося запроса.

06.12.2023    5388    user1923546    26    

43

Начните уже использовать хранилище запросов

HighLoad оптимизация Запросы

Очень немногие из тех, кто занимается поддержкой MS SQL, работают с хранилищем запросов. А ведь хранилище запросов – это очень удобный, мощный и, главное, бесплатный инструмент, позволяющий быстро найти и локализовать проблему производительности и потребления ресурсов запросами. В статье расскажем о том, как использовать хранилище запросов в MS SQL и какие плюсы и минусы у него есть.

11.10.2023    16184    skovpin_sa    14    

98
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. vano-ekt 123 31.08.16 10:38 Сейчас в теме
имхается мне, что "обычный метод" - веб-сервис, возвращающий результат, будет отрабатывать в 30-50 раз быстрее comконнектора-а из статьи
как вообще два слова "COMConnector" и "скорость" оказались рядом? :)
Nikola_N; DrAku1a; user600603_v.soldatova; PrinzOfMunchen; Bazin; +5 Ответить
2. Aphanas 92 31.08.16 12:39 Сейчас в теме
(1) vano-ekt, За скорость веб-сервис vs COM-соединение сказать не берусь, но чтобы реализовать ч/з Веб-сервис, надо что-бы был веб-сервер, вроде бы. Кроме того, надо менять конфигурацию.
> как вообще два слова "COMConnector" и "скорость" оказались рядом? :)
Проверял на разных базах - быстрее работает почему-то. Сам в шоке.
3. klinval 337 02.09.16 14:56 Сейчас в теме
Спасибо за статью!
Тоже возникала такая идея: если нельзя ходить на сервер, сходить туда фактически через Com. Но задач когда "нельзя" так и не поступило. А про скорость (то что быстрее будет через Com) не думал и не знал. Если когда-нибудь пригодится: обязательно попробую 2 варианта (классический и через Com) и посмотрю кто быстрее.
4. tormozit 7136 03.09.16 12:24 Сейчас в теме
А не проще ли толстый клиент запустить?
5. Aphanas 92 03.09.16 13:50 Сейчас в теме
(4) tormozit, Это хороший вопрос. Он может послужить началом длинного разговора о целесообразности толстого и тонкого клиента и вообще о подобной архитектуре. А если говорить кратко, то я бы с удовольствием запустил толстый клиент, но, к сожалению, его будущее у 1С выглядит весьма туманным.
6. tormozit 7136 03.09.16 19:34 Сейчас в теме
(5) это будущее может и внешнее соединение убрать в туман, т.к. по сути толстый клиент = внешнее соединение + UI.
7. Aphanas 92 03.09.16 19:58 Сейчас в теме
(6) tormozit, Согласен, но это произойдет, по крайней мере, не раньше, чем об этом скажет Microsoft.
Microsoft давно похоронило бы COM, и .NET - есть шаг именно в этом направлении, но у них еще слишком много клиентов, использующих старый хлам. Хотя рано или поздно это произойдёт.
8. Yashazz 4709 05.09.16 19:55 Сейчас в теме
Интересно. Подозреваю, действительно возможны ситуации, когда com-соединение будет быстрее. Я вот только не знаю, используются ли при таких соединениях сеансовые данные клиента и как именно, и что туда пихается, и как кэшируется. Может, оно засчёт прогрева кэша выезжает?... Или вы однократную операцию меряли?
9. Aphanas 92 05.09.16 20:51 Сейчас в теме
(8) Yashazz, Непонятно, что имеется ввиду под сеансовыми данными клиента.
Сам COM-объект находится на клиенте. Проще всего представить его как отдельный процесс. Это процесс 1С, это он обеспечивает связь с сервером. Скорее всего теми же механизмами, что и в толстом клиенте.
Когда я замерял, я старался исключить влияние возможного кэша, если он есть. Просто мерил несколько раз подряд, пока результат не стабилизировался.
Ускорение возникает, на мой взгляд, за счет эффективной работы объекта "РезультатЗапроса". Он формируется относительно быстро. Его содержимое нельзя посмотреть в отладчике, мы не можем обратиться к записи по индексу. Такое ощущение, что где-то там используется что-то вроде последовательного доступа. И, скорее всего, в асинхронном режиме. Т. е. когда мы извлекаем из него первую запись, основная часть данных находится еще где-то за пределами сервера 1С. И в теории, мы можем начать заполнение какой-нибудь коллекции уже через каких-то 1-2 секунды после того, как мы только отправили запрос на выполнение. И если мы всё делаем на сервере, то так оно и будет.
Однако в режиме "тонкий клиент-сервер", получить первую запись из него на клиенте мы можем только после полного обхода всего результата запроса. Это необходимо, как минимум, чтобы его сериализовать. Пытаться передавать данные последовательно в этом режиме просто нереально. Сервер инициализирует контекст при каждом вызове. И это беда.
Всё было бы по другому, если бы клиент общался с сервером 1С также последовательно и в асинхронном режиме. Но это уже что-то из области фантастики.
10. webester 26 06.09.16 04:41 Сейчас в теме
Немного не понял смысла статьи, если вкратце:
1. Передача данных между клиент-сервер тормозит из за сериализации\десериализации не примитимвных типов.
2. Комобъект разрешает передавать только примитивные типы, проблемы из п.1 нет.
Я где то ошибся?
11. Aphanas 92 06.09.16 11:04 Сейчас в теме
(10) webester, Факт в том, что получить данные на клиенте предлагаемым способом можно в 3-5 раз быстрее, это реально работает, можно проверить. Почему это так, я могу только предполагать.
Передача тормозит не столько из-за сериализации именно не примитивных типов, сколько вообще из-за сериализации 1С. Насколько я понимаю, 1С всё это перегоняет в XML. XML - это всегда не лучший вариант с точки зрения быстродействия, но главная проблема на в XML, в том, что я описал выше, см. (9)
12. V.Nikonov 120 09.09.16 20:13 Сейчас в теме
В основном выигрыш возможен, если не весь объем данных в реальности используется. У части записей не используются некоторые поля, за счет программной логики пропускается "обработка части записей".
Несколько меньше должно влиять факт, что "обработка на клиенте" происходить только после полной сериализации (и передачи) всего пакета. При ComConnect получение данных размазывается и ведется параллельно с "обработкой".
13. Aphanas 92 10.09.16 16:20 Сейчас в теме
(12) V.Nikonov, Можно поставить эксперимент. Странно то, что "размазывание" получения данных даёт ощутимый выигрыш. Я набросал обработку, которая позволяет сравнить передачу данных в двух режимах - стандартным способом (ч/з ЗначениеВРеквизитФормы) и через COM.
Обработке надо указать текст запроса (конструктор запроса вызывается по правой кнопке). Запрос должен выдавать одно поле типа "Строка". Называться это поле должно "Значение". Потом нажимаете либо "Получить стандартно", либо "Получить через COM". Время засекается автоматически.

В моих условия получились следующие результаты.
Текст запроса:
ВЫБРАТЬ
	РеализацияТоваровУслуг.Номер КАК Значение
ИЗ
	Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг

Время передачи стандартным способом: 205 сек.
Время передачи через COM: 38 сек.

Получилось быстрее более чем в 5 раз. Какими накладными расходами это объяснить, сам не понимаю.
Прикрепленные файлы:
ТестПередачиНаКлиентЧерезCOM.epf
14. starik-2005 3033 13.09.16 15:20 Сейчас в теме
(13) а пробовали делать то же самое с помощью процедуры c &НаСервереБезКонтекста?

Т.е. взять, и написать так:
&НаСервереБезКонтекста
Процедура П1()
  Запрос = Новый Запрос("ВЫБРАТЬ
  |    РеализацияТоваровУслуг.Номер КАК Значение
  |ИЗ
  |    Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг");
  Возврат Звапрос.Выполнить().Выгрузить().ВыгрузитьКолонку("Значение");
КонецПроцедуры

&НаКлиенте
...
...
Для Каждого А ИЗ П1() Цикл
  ТаблицаЗначений.Добавить().Значение = А;
КонецЦикла;

Показать


Быстрее Вашего решения получается или нет?
15. Aphanas 92 14.09.16 04:27 Сейчас в теме
(14) starik-2005, У меня получается примерно следующий результат:

Выборка = РезультатЗапроса.Выбрать();
Пока Выборка.Следующий() Цикл
	ДанныеФормыЭлементКоллекции = ДанныеФормыКоллекция.Добавить();
	ДанныеФормыЭлементКоллекции.Значение = Выборка.Значение;
КонецЦикла;

10 сек

ТаблицаЗначенийCOM = РезультатЗапроса.Выгрузить();
Для каждого СтрокаТаблицыЗначенийCOM из ТаблицаЗначенийCOM Цикл
	ДанныеФормыЭлементКоллекции = ДанныеФормыКоллекция.Добавить();
	ДанныеФормыЭлементКоллекции.Значение = СтрокаТаблицыЗначенийCOM.Значение;
КонецЦикла;

13 сек

МассивCOM = РезультатЗапроса.Выгрузить().ВыгрузитьКолонку("Значение");
Для каждого Значение из МассивCOM Цикл
	ДанныеФормыЭлементКоллекции = ДанныеФормыКоллекция.Добавить();
	ДанныеФормыЭлементКоллекции.Значение = Значение;
КонецЦикла;

8 сек
16. starik-2005 3033 14.09.16 15:30 Сейчас в теме
(15) Вы не поняли сути. Я предлагаю выполнить запрос на сервере без контекста (т.е. вообще без СОМ), потом передать результат в виде массива назад, а потом уже на клиенте заполнить. В Ваших вариантах я подобного не нашел. Есть мнение, что таи, как предлагаю я, будет некоторым образом быстрее, но мне особо не на чем тестить.
17. Aphanas 92 15.09.16 05:05 Сейчас в теме
(16) starik-2005, Проверил.
Схема такая:
МассивЗначений = ПолучитьДанныеНаСервереБезКонтекста(ТекстЗапроса)

Время на выполнение запроса не учитывается, как и в предыдущих случаях.

По предыдущим способам у меня получились теже самые секунды, а по этому так: сам массив получается довольно быстро - 9 сек. Еще 6 сек. уходит на заполнение коллекции, итого 15 сек. Для сравнения, через ЗначениеВРеквизитФормы на сервере - 46 сек.
18. starik-2005 3033 15.09.16 14:53 Сейчас в теме
(17) а это связано с тем, что сервер готовит форму с заполненными данными, после чего полностью именно форму и коллекцию формы сериализует и передает на клиент для отображения. Видимо сама подготовка контекста формы на сервере занимает существенное время, а не передача данных с клиента на сервер и обратно. Это проблема криворукости и лени программистов из 1С, реализовавших данный механизм через какое-то далекое место (аля запроса в цикле).
r.zdorkin; +1 Ответить
Оставьте свое сообщение