Обмен данными между информационной базой и мобильным клиентом

В каком формате передавать данные между информационной базой на сервере и мобильным клиентом.

Добрый день.

Хочу поделиться моими наблюдениями относительно обмена данными между типовой (или не типовой) информационной базой и базой, расположенной на мобильном клиенте. Основной проблемой такого обмена является размер файла. Во-первых, веб-сервис (а именно он является наиболее удобным способом обмена) имеет ограничения по размеру. Во-вторых, часть взаимодействия клиент-сервер будет осуществляться посредством мобильного интернета (EDGE, 3G, 4G) и поэтому, время на передачу пакета в 20кб и в 2мб будет различно (не в пользу последнего).

В связи с этим, решил провести пару тестов, которые показали бы производительность и результативность нескольких вариантов подготовки пакетов для обмена.
Исходными данными будет массив ссылок на объекты различного типа (в моем примере было примерно 700000 ссылок на Задачи.Задача, Справочник.Номенклатура, Документ.ВнутреннийЗаказ).

Вариант А:

1. Сериализуем массив, помещаем в xml.
2. Архивируем xml.

Вариант Б:

1. Помещаем массив в хранилище значений (без сжатия).
2. Сериализуем хранилище значений, помещаем в xml.
3. Архивируем xml.

Вариант В:

1. Помещаем массив в хранилище значений (сжатие 9).
2. Сериализуем хранилище значений, помещаем в xml.
3. Архивируем xml.

Результаты:

Вариант А

Время сериализации (с): 19.675 (сериализуется массив с 700000 элементами, помещается в xml)
Время архивирования (с): 2.403 (архивируется полученный xml файл)
Размер стандартный: 121 129,2кб (размер полученного xml)
Размер архива: 4 423,4кб (размер архива)

Вариант Б

Время получения хранилища (с): 1.467 (в хранилище помещается массив с 700000 элементами, без сжатия)
Время сериализации (с): 8.175 (сериализуется хранилище, помещается в xml)
Время архивирования (с): 2.449 (архивируется полученный xml файл)
Размер стандартный: 78 350,95кб (размер полученного xml)
Размер архива: 6 807,34кб (размер архива)

Вариант В

Время получения хранилища (сжатого) (с): 6.147 (в хранилище помещается массив с 700000 элементами, сжатие 9)
Время сериализации (с): 0.562 (сериализуется хранилище, помещается в xml)
Время архивирования (с): 0.546 (архивируется полученный xml файл)
Размер стандартный: 5 293,02кб (размер полученного xml)
Размер архива: 3 926,88кб (размер архива)

Как видно по результатам теста, оптимальным (в плане производительности и размера полученного файла обмена) является вариант В — т.е. сначала помещаем в хранилище значений с сжатием, потом архивируем (хотя на самом деле выигрыш от архивирования не такой уж и большой, пусть даже при минимальных временных затратах).

Этот пример рассматривает отправку данных с сервера на мобильный клиент. Для отправки данных с мобильного клиента на сервер вариант В думаю будет также оптимальным (с учетом того, что вариант А не подходит в принципе, ибо архивирование в мобильном клиенте сейчас недоступно).

10 Comments

DitriX 04.08.2014 at 18:00

Что есть такое архивирование? Видь сжатие хранилища это тоже архивирование.

Какую степень сжатия на каком этапе использовали?

Reply ↓
spezc 04.08.2014 at 19:16

(1) DitriX, вы правы. Сжатие данных при помещение в хранилище значений и ЗаписьZipФайла используют общий алгоритм сжатия данных «Deflation». Дополнительное использование ЗаписьZipФайла приведено для сравнения — видно, что даже после сжатия в варианте В ЗаписьZipФайла уменьшает размер еще на 20%.

В хранилище значений использовалась максимальная степень сжатия 9. В ЗаписьZipФайла использовалось степень Оптимальная (по умолчанию). Использование в ЗаписьZipФайла максимальной степени сжатия дало увеличения времени сжатия, но фактически не дало выигрыша в размере.

Reply ↓
DrAku1a 05.08.2014 at 08:40

Подскажите, а какими средствами Вы будете передавать полученный ZIP-файл на мобильное приложение и обратно?

Reply ↓
spezc 05.08.2014 at 17:07

(3) DrAku1a, на самом деле передавать ZIP-файл на мобильное приложение смысла пока нет, ибо там нет средств для распаковки. Соответствено запаковать на мобильном устройстве тоже не получится. Получение ZIP-файла здесь только как пример.

Если же обмен будет проиходить между обычными конфигурациями (есть возможность использовать zip) — то zip-файл можно будет передать в виде двоичных данных.

Reply ↓
flyer 06.08.2014 at 08:50

начиная с версии 8.3.5 мобильной платформы необходимо данные сначала бить на пакеты и только потом их передавать.

Reply ↓
spezc 06.08.2014 at 09:12

(5) flyer, а что вы имеет ввиду под «бить на пакеты»?

Reply ↓

bydk 06.08.2014 at 11:57

(9) zelevova, приведу фрагмент из Корп версии документооборота, там файлы для обмена делятся на части по 5 мб:

 // Файл с сообщением обмена разделяется на части по 5 Мб для стабилизации передачи на мобильный клиент
МассивЧастейФайла = РазделитьФайл(ИмяВременногоФайла, 5 * 1024 * 1024);

МассивЧастей = Новый Массив;
Для Каждого ИмяФайла Из МассивЧастейФайла Цикл
ДвоичныеДанные = Новый ДвоичныеДанные(ИмяФайла);
// Каждая часть сообщения максимально сжимается
МассивЧастей.Добавить(Новый ХранилищеЗначения(ДвоичныеДанные, Новый СжатиеДанных(9) ) );
УдалитьФайлы(ИмяФайла);
КонецЦикла;

Показать

ИмяВременногоФайла — это xml файл с данными…

Reply ↓

spezc 06.08.2014 at 12:24

(7) DitriX, я не знал про эту ошибку. Просто в практике встречал что у веб-сервиса встречаются проблемы при попытке пропихнуть через него файлы 50-100мб.

А все-таки, что значить «бить на пакеты»? Какие действия под этим подразумеваются?

Reply ↓
DitriX 06.08.2014 at 12:58

(6) Вероятно имелся ввиду этот баг:

Передача файлов на веб-сервис

Код ошибки: 10139716

Статус: Исправлена в будущей версии Зарегистрирована: 27.05.2014

Исправлена: «Мобильная платформа», версия 8.3.5

Описание:

На устройстве под управлением ОС Андроид не работает передача больших файлов на веб-сервис.

Она еще не исправлена.

Reply ↓
zelevova 06.08.2014 at 14:09

(5) flyer, а можно про это поподробнее?

Reply ↓

Обмен данными между информационной базой и мобильным клиентом

Related Posts

10 Comments

Leave a Comment Отменить ответ