При переходе на новые релизы платформы (с 8.3.10 на 8.3.12, 8.3.13 и выше) многие специалисты столкнулись с необъяснимым снижением производительности. Особенно остро проблема проявилась на серверных операционных системах прошлых поколений, таких как Windows Server 2003/2008. В данной статье мы разберем технические причины этого явления, проанализируем изменения в архитектуре платформы и выясним, какие шаги необходимо предпринять для восстановления нормальной скорости работы.
Одной из фундаментальных причин нестабильности и «тяжести» новых релизов стал масштабный внутренний рефакторинг. Разработчики 1С начали перевод кода платформы на стандарт C++17. Рассмотрим подробнее, что это означает для конечного пользователя. Рефакторинг такого уровня подразумевает переписывание базовых механизмов управления памятью и объектами, которые не менялись годами. В версиях 8.3.12 и 8.3.13 мы наблюдаем промежуточный этап, когда старый «некрокод» соседствует с новыми оптимизированными библиотеками. Это может вызывать конфликты на уровне системных вызовов, особенно в 32-битных средах.
Многие пользователи отмечают, что «тормозит гуй» — то есть задержки возникают именно при отрисовке форм, нажатии на кнопки или переключении между окнами. Проанализируем ситуацию: начиная с версии 8.3.12, 1С изменила механизмы взаимодействия с графической подсистемой ОС. На устаревших ОС Windows системные вызовы GDI могут отрабатывать некорректно с новым движком отрисовки форм. Это приводит к фризам интерфейса на 1-2 секунды, которые не фиксируются стандартными замерами производительности (ТЖ или консоль запросов), так как проблема лежит в клиентской части.
Разберем техническую деталь, упомянутую разработчиками: использование механизмов оптимизации памяти для строковых данных. В платформе применяются две технологии:
Строка2 = Строка1) физического копирования данных не происходит — увеличивается лишь счетчик ссылок. Копирование выполняется только в момент попытки изменения строки.Несмотря на кажущуюся пользу, в переходных версиях платформы (8.3.12) ошибки в реализации этого механизма могли приводить к избыточному потреблению памяти и нагрузке на процессор при интенсивной работе с текстовыми данными в циклах.
Выясним причину, по которой 32-битные клиенты стали работать медленнее. Разработчики платформы подтвердили, что 32-битная версия компилируется с флагами совместимости для очень старого железа (уровня Pentium 4), не используя современные инструкции процессора SSE2 и выше. Это делается для поддержки «парка старых машин» у клиентов.
В то же время 64-битная платформа изначально ориентирована на современные процессоры и использует все доступные оптимизации. Рекомендация: если ваше оборудование поддерживает 64-битную архитектуру, переход на 64-битный клиент и сервер является обязательным условием для устранения «тормозов» в новых релизах.
Начиная с версии 8.3.13, в платформе появились инструменты, которые помогают бороться с зависаниями. Рассмотрим наиболее полезные из них:
Посмотрим на пример того, как в новых версиях можно управлять потреблением ресурсов. Хотя основной функционал настраивается в консоли сервера, программно мы можем контролировать длительные операции. Разберем логику управления потоками (Streams), которые появились для ДвоичныеДанные. Теперь нет необходимости постоянно сохранять временные файлы на диск:
// Пример использования потоков для оптимизации работы с памятью (доступно в 8.3.13+)
ПотокВПамяти = Новый ПотокВПамяти();
ЗаписьДанных = Новый ЗаписьДанных(ПотокВПамяти);
ЗаписьДанных.ЗаписатьСтроку("Пример данных для передачи");
ЗаписьДанных.Закрыть();
ДанныеРезультат = ПотокВПамяти.ЗакрытьИПолучитьДвоичныеДанные();
// Теперь данные передаются без записи на жесткий диск, что ускоряет работу GUI
Проанализируем ситуацию и составим план действий для тех, кто столкнулся с проблемами на версии 8.3.12:
SSE, что значительно ускоряет отрисовку управляемых форм.Shared Memory. Если антивирус заставляет систему общаться через TCP/IP (loopback), задержки интерфейса неизбежны.C++17 уже исправлены, а стабильность работы с памятью выше.rphost, а точечно устранять проблему.Подводя итог, можно сказать, что «тормоза» в 8.3.12 — это следствие перехода платформы на более современные технологии при сохранении обратной совместимости. Оптимизация системы сегодня требует отказа от устаревших 32-битных архитектур и перехода на актуальное системное программное обеспечение.