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, так как новый процесс не может запуститься. В таком случае, нужно принять меры по минимизации числа запросов в процессе передачи со стороны СУ.