← На главную

При совместной разработке крупных конфигураций (например, УПП 1.3 или ERP) разработчики часто сталкиваются с существенным замедлением работы хранилища конфигурации. Операции захвата объектов, сравнения и помещения изменений могут занимать от нескольких минут до десятков минут. В попытках решить эту проблему часто возникает идея перевести хранилище с общего сетевого ресурса на веб-сервер (протоколы HTTP или TCP). Разберем подробнее, дает ли такой подход выигрыш в скорости, выясним причины медленной работы и рассмотрим проверенные способы оптимизации.

Влияет ли веб-сервер на скорость работы хранилища?

Перевод хранилища конфигурации на веб-сервер по протоколам http:// или tcp:// не увеличивает скорость работы. Более того, в большинстве случаев доступ через веб-сервер работает медленнее, чем прямое подключение к файловой системе через сетевую шару (SMB).

Выясним причину этого поведения. Процесс взаимодействия Конфигуратора с хранилищем состоит из большого количества мелких синхронных запросов. При работе по HTTP/TCP к накладным расходам файлового обмена добавляется сериализация данных и задержки веб-протокола. Поэтому если основной целью перехода на веб-сервер является исключительно ускорение помещений объектов, такой подход не принесет желаемого результата.

Основные причины низкой скорости и нестабильности хранилища

Проанализируем ключевые факторы, которые замедляют работу с хранилищем конфигурации:

1. Чувствительность к сетевой задержке (Ping): Попытка поместить даже небольшие изменения приводит к сотням последовательных запросов. Если сетевой пинг между компьютером разработчика и сервером хранилища превышает 10–20 мс, скорость работы падает в десятки раз независимо от ширины интернет-канала.
2. Ограничение размера файла базы хранилища (4 Гб): При использовании классического сетевого хранилища на старых версиях платформы размер файла 1Cv8ddb.1CD ограничен 4 Гб. При превышении этого лимита хранилище разрушается и перестает открываться.
3. Нагрузка на локальный диск разработчика: В момент помещения объектов Конфигуратор 1С активно создает, читает и переписывает временные файлы на локальном компьютере. Если у разработчика установлен медленный жесткий диск (HDD), именно он становится узким местом.
4. Разрастание локального кэша: Со временем в каталоге локального кэша хранилища у пользователя накапливаются устаревшие версии и временные файлы, что вызывает задержки при проверке статусов захвата объектов.

Способы оптимизации и ускорения работы хранилища

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

1. Очистка и настройка локального кэша хранилища

Первым делом очистим локальный кэш хранилища на рабочей станции разработчика. Это устранит подвисания при сравнении и помещении объектов.

Выполнить очистку можно двумя способами:

1. Сбросить кэш через запуск Конфигуратора из командной строки с ключом: 1cv8.exe DESIGNER /F "C:\Bases\MyBase" /ConfigurationRepositoryClearCache
2. Удалить содержимое каталога кэша вручную. Для этого перейдем по пути:

   %LOCALAPPDATA%\1C\1Cv8\<ID_пользователя>\cfgrepo

   Удалим все папки и файлы внутри этого каталога (если необходимо сохранить историю введенных комментариев, файл comments можно оставить).

Также настроим лимит локального кэша. В окне Конфигуратора перейдем в меню Конфигурация — Хранилище конфигурации — Настройка использования локальных данных хранилища и ограничим максимальный размер кэшируемых данных.

2. Перевод разработки на RDP (Терминальный сервер)

Разберем наиболее эффективный архитектурный ход для устранения сетевых задержек. Если перенести рабочие места разработчиков на терминальный сервер (RDP), находящийся в одной локальной сети с хранилищем (или на том же физическом хосте), сетевой пинг снизится до значений менее 1 мс. В этом случае операции, занимавшие 10 минут, начинают выполняться за несколько секунд.

3. Отключение режима совместимости хранилища (Платформа 8.3)

Начиная с платформы 1С:Предприятие 8.3, механизм хранилища конфигурации получил существенное обновление формата хранения данных.

Важно учитывать: режим совместимости самого хранилища не зависит от режима совместимости разрабатываемой конфигурации. Чтобы отключить режим совместимости хранилища:

1. Откроем меню Конфигурация — Хранилище конфигурации — Администрирование хранилища.
2. В поле режима совместимости установим значение "Не использовать".

После этого формат хранилища трансформируется: основной файл 1Cv8ddb.1CD будет хранить только индексы и структуру метаданных, а сами версии объектов вынесутся в отдельный каталог data. Это полностью снимает ограничение в 4 Гб и предотвращает падение базы хранилища при активной разработке.

4. Использование производительных накопителей (NVMe SSD)

Поскольку хранилище активно генерирует дисковые операции ввода-вывода (IOPS), установка современных NVMe SSD-дисков на сервере хранилища и на локальных ПК разработчиков дает ощутимый прирост скорости при сравнении и объединении конфигураций.

Альтернативные подходы к организации разработки

Если работа с классическим хранилищем 1С остается медленной из-за большого объема метаданных конфигурации (как в УПП 1.3 или ERP), рассмотрим современные альтернативные сценарии:

1. Разработка в "легких" локальных демо-базах: Разработчик подключается к хранилищу из минимальной информационные базы без тяжелых учетных данных. Это снижает время обновления конфигурации базы данных в несколько раз.
2. Выгрузка конфигурации в файлы и использование Git: С помощью штатной команды Конфигурация — Выгрузить конфигурацию в файлы конфигурация разбирается на отдельные XML-файлы. Это позволяет использовать внешние системы контроля версий (Git) и инструменты вроде gitsync для синхронизации изменений.
3. Переход на 1C:EDT (Enterprise Development Tools): Среда разработки 1C:EDT работает напрямую с исходными файлами проектами и распределенной системой Git, полностью избавляя от проблем классического хранилища 1С.