gifts2017

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

Опубликовал Алексей Апанасович (Aphanas) в раздел Программирование - Практика программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

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

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

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

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

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

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

...Показать Скрыть


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

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

10 сек

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

13 сек

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

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

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

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