При работе с распределенными информационными базами (РИБ) многие администраторы и разработчики сталкиваются с парадоксальной ситуацией: файл конфигурации .cf весит, например, 400 МБ, а после его обновления в центральном узле файл выгрузки для периферийных баз раздувается до 900 МБ и более. Это создает серьезные проблемы для торговых точек с медленным или нестабильным интернет-каналом. В данной статье мы подробно разберем причины такого поведения платформы 1С и проанализируем способы оптимизации этого процесса.
Проанализируем структуру пакета обновления, который формирует платформа. Когда мы обновляем конфигурацию в центральном узле, система должна передать эти изменения в периферийные базы. Основная причина двукратного увеличения размера заключается в том, что в файл обмена включаются две составляющие:
Кроме того, не стоит забывать про технический аспект передачи данных. Сообщение обмена РИБ — это текстовый файл формата XML. Все бинарные данные, включая саму конфигурацию, кодируются в формат Base64. Это преобразование само по себе увеличивает объем данных примерно на 30–33%. Если сложить «двойную» конфигурацию и накладные расходы на кодирование, мы как раз получим рост с 400 МБ до 900–1000 МБ.
Рассмотрим, почему в старых решениях (например, УТ 10.3) эта проблема не стояла так остро. Современные конфигурации, такие как Розница 2.3 или 3.0, построены на базе Библиотеки стандартных подсистем (БСП). Это влечет за собой следующие последствия:
.cf файла вырос в десятки раз.Выясним, как можно радикально уменьшить размер пакета. Если вы сопровождаете сильно доработанную базу и не планируете обновлять периферийные узлы стандартными средствами напрямую с портала 1С, конфигурация поставщика в этих узлах фактически не нужна.
Алгоритм действий:
Важно: Это решение имеет свои риски. После снятия с поддержки вы не сможете использовать механизм автоматического обновления через «Поиск обновлений». Вам придется обновлять центральную базу вручную через сравнение/объединение с новым .cf файлом от 1С. Однако для ПБ это не критично, так как они в любом случае получают изменения от центра.
Если интернет-канал не позволяет передать даже 400 МБ, мы можем применить методику «ручной заливки». Это позволит избежать передачи тяжелого блока конфигурации через транспорт обмена.
Рассмотрим пошагово:
.cf из центральной базы.В этом случае платформа увидит, что номера версий конфигураций в ЦБ и ПБ совпадают, и передаст в файле обмена только фактические данные (документы, справочники), что составит всего несколько мегабайт вместо сотен.
Проанализируем ситуацию с торговым оборудованием. В 1С:Розница общие макеты с драйверами могут занимать до половины объема всей базы. Если в ваших магазинах используется только один вид фискальных регистраторов и эквайринга, остальные драйверы просто лежат «мертвым грузом».
Некоторые разработчики практикуют удаление ненужных макетов из БСП в основной конфигурации. Это позволяет сократить исходный .cf файл, что автоматически уменьшит и файлы обмена РИБ. Однако помните, что при следующем обновлении на новый релиз типовой конфигурации вам придется снова аккуратно вычищать эти объекты.
Иногда объем выгрузки остается большим даже при незначительных правках. Это происходит из-за механизма регистрации изменений. Посмотрим на пример кода, который можно использовать для программного анализа состава изменений в узле:
Узел = ПланыОбмена.ПоМагазинам.НайтиПоКоду("МАГ01");
ВыборкаИзменений = ПланыОбмена.ВыбратьИзменения(Узел, НомерСообщения);
Пока ВыборкаИзменений.Следующий() Цикл
Сообщить("Изменен объект: " + Строка(ВыборкаИзменений.Получить()));
КонецЦикла;
Если вы видите в списке регистрации объекты Конфигурация, это значит, что при обмене будет предпринята попытка передать метаданные. Чтобы пакеты не «зацикливались» и не пересылались повторно при обрывах связи, рекомендуется контролировать квитирование сообщений и, при необходимости, временно увеличивать таймауты соединения в настройках синхронизации данных.