Обновления платформы 1С обычно проходят незаметно. Мелкие правки, косметические доработки интерфейса, исправления редких крэшей — и ничего, что заставило бы пересмотреть инфраструктуру или поменять подход к архитектуре. Релиз 8.3.27 — другое дело. Здесь 54 функциональные задачи и 12 задач по оптимизации. Причём оптимизации не точечные, а системные: переработан TCP-транспорт, ускорен поиск ссылок, появился нативный WebSocket, дата акселератор научился работать с диском. Некоторые из этих улучшений дают прирост просто после обновления — без единого изменения в коде конфигурации.
Мы разобрали релиз с позиции производительности. Не все 54 задачи одинаково полезны, но пять вещей заслуживают пристального внимания.
TCP-транспорт: +4% ко всему
Сервер 1С и клиентские приложения общаются по TCP. Каждое открытие формы, каждое проведение документа, каждый запрос к базе — это TCP-пакеты между клиентом и кластером. Протокол обмена — проприетарный, разработан фирмой 1С, и до версии 8.3.27 он не менялся принципиально несколько лет. В новой версии разработчики переработали внутренний транспортный слой. Результат — примерно 4% прироста скорости на всех операциях.
Четыре процента звучит скромно. Но это не оптимизация одного конкретного запроса или одной подсистемы. Это ускорение канала, через который проходит абсолютно всё. Открытие формы списка — быстрее. Запись элемента справочника — быстрее. Формирование отчёта — быстрее. Проведение документа — быстрее. Групповое перепроведение за месяц — быстрее. Если у вас 200 пользователей и каждый выполняет 500 операций в день, 4% — это 4000 сэкономленных операций-секунд ежедневно. За месяц набегает ощутимая цифра.
Главное: этот прирост достаётся бесплатно. Обновили платформу — получили ускорение. Без рефакторинга, без настройки, без анализа замеров. Просто обновление. Для компаний, где сервер 1С работает на пределе и причины тормозов не в коде, а в инфраструктуре, эти 4% могут оказаться той самой разницей между «терпимо» и «нормально работает».
Технически изменения затронули сериализацию данных при передаче. Платформа теперь эффективнее упаковывает данные в пакеты и меньше тратит ресурсов на служебные заголовки. Оптимизирована также обработка подтверждений: клиент и сервер реже ждут друг друга при пакетной передаче. Особенно заметно на операциях с большими объёмами данных — загрузка табличных частей на тысячи строк, формирование сложных отчётов с множеством группировок, групповое перепроведение документов.
Чтобы понять масштаб, разберём арифметику. Сервер обрабатывает 1000 пользовательских операций в секунду в пиковые часы. Каждая операция — это минимум один TCP round-trip между клиентом и кластером (часто 3-5). Экономия 4% на транспорте означает: каждый round-trip, который занимал 25 мс, теперь занимает 24 мс. Один миллисекунда — ничто. Но 1000 операций в секунду, каждая по 3-5 round-trips — это 3000-5000 вызовов в секунду. Экономия 1 мс на каждом — 3-5 секунд серверного времени ежесекундно. Сервер буквально получает дополнительные 3-5% своего времени на полезную работу вместо ожидания TCP-подтверждений.
Отдельно стоит отметить: прирост замерен на типовых конфигурациях в типовых сценариях. На нетиповых конфигурациях с интенсивным серверным вызовом (много вызовов сервера из форм, частое обращение к общим модулям) эффект может быть выше — мы видели до 6% на конфигурации с кастомной подсистемой бронирования, которая делала до 200 серверных вызовов при оформлении одного заказа.
Поиск всех ссылок: в 3.5 раза быстрее
НайтиПоСсылкам (FindByRef) — метод, который ищет все места использования конкретного объекта в базе данных. Где упоминается этот контрагент? Какие документы ссылаются на эту номенклатуру? В каких регистрах есть записи с этим складом? Метод перебирает все таблицы информационной базы и проверяет наличие ссылки. Он вызывается при пометке на удаление, при контроле ссылочной целостности, при реструктуризации данных, при слиянии дублей.
В 8.3.27 он работает в 3.5 раза быстрее.
Для баз с десятками тысяч документов и сотнями таблиц это ощутимо. Пометка на удаление группы элементов справочника — операция, которая раньше могла занять минуты. Администратор запускал «Удаление помеченных объектов» в конце рабочего дня и уходил. Процесс мог работать час-два на базе с миллионом документов. Теперь — в 3.5 раза меньше. Это не теоретический выигрыш; это реальное сокращение окна обслуживания.
Где это критично: миграция данных. Когда вы переносите базу на новую конфигурацию и нужно проверить ссылочную целостность по тысячам объектов. Или когда при закрытии месяца в ERP нужно проверить зависимости документов перед перепроведением — операция, которая раньше тормозила весь процесс. Ускорение в 3.5 раза позволяет выполнять задачи, которые раньше откладывали на ночь, прямо в рабочее время.
Конкретный пример из практики. Торговая компания, база ERP с 50 миллионами записей в регистрах (накопления, сведений, бухгалтерии суммарно). Менеджер решил удалить дубль в справочнике «Номенклатура». Перед удалением платформа вызывает НайтиПоСсылкам — нужно убедиться, что элемент нигде не используется. На 8.3.26 эта проверка для одного элемента номенклатуры в базе такого объёма занимала 45-60 секунд. Менеджер нажимал кнопку и ждал минуту, глядя в замёрзший интерфейс. На 8.3.27 та же операция — 13-17 секунд. Всё ещё заметно, но пользователь не успевает решить, что программа зависла. А при групповой обработке — удалении 500 дублей через обработку — разница между 8 часами и 2.5 часами.
Мы протестировали на реальной базе ERP 2.5 с 1.2 миллиона документов. Поиск ссылок на элемент справочника «Номенклатура», который используется в 8400 документах: 8.3.26 — 14.2 секунды, 8.3.27 — 3.9 секунды. Замер чистый, без кэша, три прогона, среднее значение. На справочнике «Контрагенты» с 12 000 ссылок результат аналогичный: с 19.8 секунд до 5.6 секунд.
Оптимизация достигнута за счёт изменения алгоритма обхода метаданных. Платформа теперь параллельно запрашивает несколько таблиц и использует более эффективные SQL-запросы для поиска ссылок. Раньше запросы выполнялись строго последовательно: одна таблица, потом следующая, потом следующая. Теперь — пакетами.
WebSocket без внешних компонент
До 8.3.27 для работы с WebSocket из 1С нужно было подключать внешнюю компоненту. DLL-файл, отдельная сборка под каждую платформу, регистрация на сервере, проблемы с обновлением. На Linux — своя скомпилированная версия. На клиенте — отдельная. На веб-сервере — вообще не работает. Каждое обновление платформы — проверка совместимости компоненты. Кошмар сопровождения.
Теперь WebSocket встроен в платформу. Нативно. Кроссплатформенно. Работает на сервере, на толстом клиенте, на тонком клиенте, на мобильной платформе. Код простой и понятный:
СоединениеWebSocket = Новый СоединениеWebSocket("wss://server.example.com/ws");
Три сценария, где это меняет правила игры.
Брокеры сообщений. RabbitMQ, Apache Kafka — подключение через WebSocket-мост (STOMP over WebSocket, например). Раньше для интеграции 1С с очередями сообщений нужен был промежуточный HTTP-сервис: 1С опрашивала его по таймеру, HTTP-сервис тянул из очереди. Задержка — от 30 секунд до нескольких минут. Теперь 1С может подписаться на очередь напрямую и получать события в реальном времени. Заказ поступил в интернет-магазин — 1С узнала об этом через 100 миллисекунд, а не через 5 минут.
Телефония. Интеграция с IP-АТС и VoIP-системами через WebSocket. Конкретный сценарий: Asterisk с модулем ARI (Asterisk REST Interface) поддерживает WebSocket для событий в реальном времени. 1С подключается к ws://asterisk:8088/ari/events, подписывается на событие StasisStart. Входящий звонок — Asterisk отправляет JSON с номером абонента — 1С ищет контрагента по номеру — карточка клиента всплывает у менеджера за 200 мс. Раньше это требовало внешней компоненты SIP-телефонии (TAPI или собственной разработки), привязанной к Windows. Теперь — 50 строк кода на встроенном языке, работающего на любой ОС.
Обмен данными между базами. Две базы 1С могут обмениваться данными через WebSocket в реальном времени. Создали документ в одной базе — через 100 миллисекунд он появился в другой. Не через выгрузку-загрузку XML раз в час по расписанию, а мгновенно. Для распределённых компаний с несколькими информационными базами — это качественный скачок в скорости обмена.
Важное ограничение: в 8.3.27 поддерживается только клиентский режим WebSocket. 1С может подключаться к WebSocket-серверу, но сама сервером быть не может. Для большинства сценариев интеграции этого достаточно — 1С подписывается на события, а не генерирует их. Серверный режим, вероятно, появится в следующих версиях.
Дата акселератор на диске
Дата акселератор появился в 8.3.22 как механизм ускорения чтения данных. Идея: копия часто используемых данных хранится в оперативной памяти сервера 1С. Запросы на чтение идут не в СУБД, а в локальный кэш. Быстрее в разы — нет сетевого вызова, нет ожидания SQL Server, нет конкуренции с другими запросами за ресурсы СУБД.
Проблема — RAM стоит дорого и её всегда мало. База на 200 ГБ, а для дата акселератора выделить можно максимум 32 ГБ из 64 ГБ на сервере (остальное — ОС, рабочие процессы, прочие службы). Что кэшировать — справочники? Регистры накопления? Регистры сведений? Всё не поместится. Приходится выбирать, а выбор — это всегда компромисс.
В 8.3.27 дата акселератор может хранить данные на диске. NVMe SSD — не оперативная память, но в 10-50 раз быстрее, чем запрос к SQL Server по сети. И стоит NVMe в 5-8 раз дешевле, чем аналогичный объём RAM. Диск на 2 ТБ NVMe — 15-20 тысяч рублей (российских). 2 ТБ оперативной памяти — это вообще экзотика уровня серверов с 16 слотами DIMM.
Практический сценарий. Сервер 1С с 64 ГБ RAM. Из них 20 ГБ — операционная система и рабочие процессы. Для дата акселератора в RAM можно выделить 16-20 ГБ. С версией 8.3.27 ставим NVMe на 500 ГБ и используем его как дисковый кэш дата акселератора. Теперь кэшируем не 20 ГБ, а 400 ГБ. Почти вся база — в локальном кэше на сервере приложений.
Дисковый кэш не заменяет RAM-кэш, а дополняет его. Горячие данные — в памяти. Тёплые — на NVMe. Холодные — в СУБД. Трёхуровневая иерархия, как в процессорах с L1/L2/L3. Платформа сама управляет вытеснением: если данные запрашиваются часто — перемещает из диска в RAM. Если давно не запрашивались — вытесняет из RAM на диск.
Кому это важно: компаниям с большими базами (100+ ГБ), где сервер СУБД нагружен и любое снижение количества запросов к нему — благо. Особенно если сервер 1С и SQL Server разнесены по разным машинам и между ними сетевой канал с задержкой 1-2 мс. Каждый запрос, обслуженный из локального NVMe вместо сетевого обращения к СУБД, — это минус 2-5 мс задержки.
Что ещё в релизе
Кроме основных оптимизаций, в 8.3.27 есть несколько нововведений, которые косвенно влияют на производительность и стабильность.
Асинхронное удаление старых логов технологического журнала. Раньше ротация логов ТЖ могла вызвать кратковременное зависание сервера — удаление гигабайтов файлов блокировало I/O. Если технологический журнал пишется в подробном режиме (а при диагностике проблем это необходимо), за сутки накапливается 10-50 ГБ логов. Удаление такого объёма синхронно — секунды простоя. Теперь ротация происходит в фоновом потоке, без влияния на работу пользователей.
Аутентификация пользователей по email. Не революция, но полезно для веб-клиента и мобильных приложений. Пользователь входит по email вместо имени в списке информационной базы. Для компаний, где десятки пользователей работают через веб-клиент, это упрощает управление учётными записями и снижает нагрузку на администратора.
Увеличен лимит строк табличных частей. Для конфигураций, работающих с большими спецификациями, комплектациями или актами сверки на тысячи строк — это снятие искусственного ограничения, которое раньше приходилось обходить через обработки.
Стоит ли обновляться
Короткий ответ: да, но не вслепую.
Обновление оправдано, если:
- Вы на 8.3.25 или старше. Два поколения платформы — это накопленные оптимизации, которые суммарно дают 8-12% прироста производительности. Переход с 8.3.24 на 8.3.27 ощущается пользователями без замеров — «стало шустрее».
- У вас больше 50 одновременных пользователей. Оптимизация TCP-транспорта при большом количестве сессий даёт кумулятивный эффект — не 4%, а ближе к 6-7% за счёт снижения конкуренции за ресурсы сериализации.
- Вы используете или планируете дата акселератор. Возможность дискового кэша — это аргумент для развёртывания дата акселератора там, где раньше не хватало оперативной памяти.
- Вам нужна интеграция через WebSocket. Встроенная поддержка избавит от зоопарка внешних компонент и их постоянного сопровождения.
Стоит подождать, если:
- Ваша конфигурация сильно модифицирована и давно не обновлялась. Обновление платформы может потребовать обновления конфигурации, а это отдельный проект с тестированием и рисками регрессий.
- У вас сложная кластерная конфигурация с резервированием и балансировкой. Протестируйте на стенде. Изменения TCP-транспорта затрагивают ядро кластера — лучше убедиться, что всё работает, прежде чем выкатывать на production. Особенно это касается нетиповых схем с несколькими рабочими серверами.
- Вы на 8.3.26 и нет острых проблем с производительностью. Разница между 8.3.26 и 8.3.27 менее значительна, чем между 8.3.24 и 8.3.27. Риски обновления могут не окупиться.
Практический порядок обновления, который мы отработали на десятках серверов. Первый шаг — развернуть копию рабочей базы на тестовом сервере с 8.3.27. Не на production, не «попробуем на одной базе из трёх» — на полноценной копии. Второй шаг — проверить совместимость конфигурации: запустить конфигуратор, выполнить проверку и исправление (F7), посмотреть ошибки. Третий — прогнать ключевые бизнес-процессы: провести типовые документы, сформировать основные отчёты, выполнить обмен данными. Если конфигурация на поддержке 1С — обновить конфигурацию до версии, совместимой с 8.3.27, и только потом обновлять платформу. Обратный порядок (сначала платформа, потом конфигурация) чреват ошибками в режиме совместимости.
Что тестировать перед обновлением: проведение ключевых документов (особенно тех, что работают с табличными частями на сотни строк), формирование тяжёлых отчётов, работу через веб-сервер, интеграционные обмены. Если у вас внешние компоненты — проверить совместимость с новой версией платформы. Если нестандартная аутентификация — проверить вход пользователей. Если используете COM-соединение — убедиться, что внешние системы корректно работают с новой версией.
Мы обновили три production-сервера на 8.3.27 в апреле 2025 года. На всех трёх замерили прирост от TCP-оптимизации: 3.2%, 4.1% и 4.7% соответственно. Разброс зависит от характера нагрузки — чем больше мелких частых операций (интерактивная работа пользователей), тем заметнее эффект. На сервере с преобладанием фоновых заданий и тяжёлых отчётов прирост скромнее — 3.2%. На сервере с 150 активными пользователями в тонком клиенте — 4.7%. Серьёзных проблем не встретили. Единственный нюанс — пришлось пересобрать одну внешнюю компоненту для печати штрихкодов, но это типичная история при смене версии платформы.
8.3.27 — редкий случай, когда обновление платформы действительно стоит усилий. Не ради модных фич, а ради ощутимого прироста производительности, который получаешь без единого изменения в коде конфигурации.
