Добрый день.
Хочу поделиться моими наблюдениями относительно обмена данными между типовой (или не типовой) информационной базой и базой, расположенной на мобильном клиенте. Основной проблемой такого обмена является размер файла. Во-первых, веб-сервис (а именно он является наиболее удобным способом обмена) имеет ограничения по размеру. Во-вторых, часть взаимодействия клиент-сервер будет осуществляться посредством мобильного интернета (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кб (размер архива)
Как видно по результатам теста, оптимальным (в плане производительности и размера полученного файла обмена) является вариант В - т.е. сначала помещаем в хранилище значений с сжатием, потом архивируем (хотя на самом деле выигрыш от архивирования не такой уж и большой, пусть даже при минимальных временных затратах).
Этот пример рассматривает отправку данных с сервера на мобильный клиент. Для отправки данных с мобильного клиента на сервер вариант В думаю будет также оптимальным (с учетом того, что вариант А не подходит в принципе, ибо архивирование в мобильном клиенте сейчас недоступно).
Хочу поделиться моими наблюдениями относительно обмена данными между типовой (или не типовой) информационной базой и базой, расположенной на мобильном клиенте. Основной проблемой такого обмена является размер файла. Во-первых, веб-сервис (а именно он является наиболее удобным способом обмена) имеет ограничения по размеру. Во-вторых, часть взаимодействия клиент-сервер будет осуществляться посредством мобильного интернета (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кб (размер архива)
Как видно по результатам теста, оптимальным (в плане производительности и размера полученного файла обмена) является вариант В - т.е. сначала помещаем в хранилище значений с сжатием, потом архивируем (хотя на самом деле выигрыш от архивирования не такой уж и большой, пусть даже при минимальных временных затратах).
Этот пример рассматривает отправку данных с сервера на мобильный клиент. Для отправки данных с мобильного клиента на сервер вариант В думаю будет также оптимальным (с учетом того, что вариант А не подходит в принципе, ибо архивирование в мобильном клиенте сейчас недоступно).
