Skip to main content

Передача данных выгрузки на сайт – в сжатом (zip архиве) и несжатом виде

21 мая, 2020 (обновлено: 11 июня, 2024)
Просмотров 1115
Section background
Версия: 1.129.0 | Последнее обновление: 28 июня 2024 | открыть

1C (СБИС, МойСклад, то есть система учета, далее СУ) может передавать выгрузку на сайт, как в сжатом виде (в zip архиве), так и в несжатом, то есть каждый файл по отдельности.

Безусловно, вариант передачи в сжатом виде является более оптимальным, так как передается меньший объем данных и меньшим числом запросов (без сжатия, каждый файл передается отдельно и отдельным запросом), что может очень существенно сэкономить, как время на передаче, в особенности, когда много картинок или размер xml велик (данные в xml содержат большое количество одинаковой информации, так как теги имеют одинаковые имена, что очень хорошо поддается сжатию, к примеру 40 мегабайт xml из выгрузки, в архиве занимают порядка 500 килобайт), так и формируемую от передачи нагрузку.

В настройках плагина принятие данных в сжатом виде включено по умолчанию, в СУ вам делать ничего не нужно это стандартное поведение и, будут данные сжиматься или нет, по сути решает принимающая сторона (конечно, если в СУ нет ошибки и она будет “вести себя” в соответствии с протоколом), сообщая в рамках протокола о том, готова она принять в сжатом виде или нет.

Работает это следующим образом.

Перед тем, как передавать данные на сайт, СУ отправляет запрос вида – “type=catalog&mode=init”, запрашивая от сайта параметры обмена, а именно, поддерживается ли передача в сжатом виде и ограничение на размер части данных, в ответ получая “zip=yes” или “zip=no” и “file_limit=значение” и уже использует полученные настройки в логике выгрузки. 

Стоит заметить, что вне зависимости от варианта не нужно “мельчить” с “размером части файла”, так как иначе, по варианту 1 весь профит сойдет на нет, а по варианту 2 помимо того, что и так каждый файл передается отдельно, но плюс к этому каждый файл будет передаваться в несколько запросов.

Но, также не нужно указывать избыточно большое значение для части файла. Во-первых оно не должно превышать ограничения на хостинге, а во-вторых стоит учитывать скорость и стабильность интернет соединения между хостингом и СУ. Плагин по умолчанию ставит значение 5000000, так как оно является достаточно оптимальным в большинстве случаев.

Вариант 1 (в архиве): Если в ответ было получено “zip=yes”, то СУ сжимает сформированную выгрузку в архив и передает его на сайт. После завершения передачи архива, СУ начинает передавать запросы вида “type=catalog&mode=import&filename=имя xml файла” на сайт для того, чтобы он обработал переданные данные, сайт получив первый такой запрос, распаковывает ранее полученный архив. 

Распаковка архива осуществляется с прогрессом, так как объем может быть большим и/или файловая система медленной, что не позволит произвести распаковка за один запрос. По завершению архив удаляется и начинается обработка указываемого СУ файла выгрузки.

Просто для понимания по размеру части файла – если общий объем данных, например, 1500 мегабайт, то при размере части 1000000 (около мегабайта), СУ передаст данные примерно за 1500 запросов, а при части в 5000000 будет уже всего 300 запросов. В идеальной ситуации, меньше запросов = меньше времени и меньше нагрузки.

Стоит заметить, что при передаче в архиве увеличивается необходимость свободного дискового пространства, ведь в момент распаковки существует и сам архив и распакованные данные. Например, если архив 1.5 гигабайта, а данных в нем 2.0 гигабайта, то для распаковки требуется 3.5 гигабайта свободного места, то есть размер архива + размер упакованных данных.

Вариант 2 (без сжатия): Если в ответ было получено “zip=no”, то СУ не сжимает выгрузку в архив, а сразу после формирования, начинает последовательную передачу на сайт, при этом каждый файл, включая картинки, передается отдельно.

Просто для понимания – если размер файла, например, XML 150 мегабайт, то при размере части 1000000 (около мегабайта), СУ передаст данные примерно за 150 запросов, а при части в 5000000 будет уже всего 30 запросов. Или, например, передаваемый файл картинки размером 1500000 (около 1.5 мегабайт), то при размере части 1000000 (около мегабайта), СУ передаст его за 2 запроса, а при размере части 100000 (около 100 килобайт), СУ передаст его за целых 15 запросов, а это что-то ужасное. В идеальной ситуации, меньше запросов = меньше времени и меньше нагрузки.

Известные проблемы.

Проблема 1.

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

Проблема 2.

Время от времени возникающая 502 в процессе передачи. В большинстве случаев, это следствие большого количества запросов со стороны СУ и, когда “выбивается” весь пул процессов в рамках ограничений на хостинге, при очередном запросе передачи от СУ будет 502, так как новый процесс не может запуститься. В таком случае, нужно принять меры по минимизации числа запросов в процессе передачи со стороны СУ.

Поделиться: