APDEX. Внедрение в УТ 11 | Компания ЗетаСофт

Опыт внедрения

10 минут

Продукты 1С

Ситуация до начала работ

На момент старта проекта клиент работал на конфигурации УТ 11.1 с многолетним слоем доработок.

База находилась в предкритическом состоянии:

Жалобы пользователей стали системными: менеджеры по продажам ожидали реакции системы по 8–10 секунд при смене контрагента, проведение документов «зависало», а помощник продаж превратился в узкое место.
Блокировки на регистре расчетов возникали ежедневно, приводя к остановке работы ключевых подразделений.
Место на диске с логами MS SQL заканчивалось несколько раз в неделю, сервер приходилось экстренно чистить.
APDEX (объективный показатель производительности) находился на уровне 0,4–0,45.

Диагностика: поиск проблемы

1. Внедрение APDEX как единой метрики
Использовали подсистему «Оценка производительности» из БСП. В старой УТ 11.1 доработали формы документов, добавив замеры в начало и конец записи на сервере. Сформировали три профиля ключевых операций: проведение основных документов, работа в помощнике продаж и фоновые взаиморасчеты. Целевое время операций подбирали по методике ИТС, отталкиваясь от оценки пользователей «очень плохо» (цель — достичь APDEX = 0,8).

2. Технологический журнал и инструмент «Монитор»
Для глубокого анализа запросов и блокировок внедрили инструмент 1smonitor.ru (АндрейБурмистров). Настроили сбор технологического журнала, чтобы видеть длительные запросы (от 5 секунд), блокировки и физическое чтение.

3. Мониторинг ресурсов сервера и СУБД
Запустили стандартный мониторинг CPU, памяти, очереди к дискам. Получили доступк MS SQL Management Studio, проверили настройки сервера баз данных. Это позволило отделить проблемы «железа» от проблем кода.

Топ проблем и их решение

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

№ / Проблема

Решение / Эффект

1. Наследство — внешние обработки выгрузки остатков.

Что нашли:
В запросах использовалось соединение виртуальных таблиц (остатки, резервы, цены) в одной временной таблице. Физическое чтение достигало десятков гигабайт, tempdb разрасталась.

Решение:
Запросы переписаны с использованием менеджера временных таблиц.

Эффект:

Нагрузка на tempdb снижена в разы, перестало заканчиваться место.

2. Обработка «Заказ под заказ» — динамический список.

Что нашли:
В динамическом списке использовались вложенные запросы и соединения виртуальных таблиц. Оптимизатор SQL не мог построить эффективный план.

Решение:
Вывод данных переделан на таблицу значений, запрос оптимизирован по стандартной методике.

Эффект:

Время формирования списка сократилось с неопределенно долгого до приемлемого.

3. Расчет сегментов номенклатуры каждые 10 минут.

Что нашли:
Штатный механизм расчета сегмента «Б/у товары» через СКД выполнялся тяжелым запросом. Оптимизации не поддавался.

Решение:
Расчет перенесен в подписку перед записью номенклатуры и характеристики. Штатное формирование оставлено ночным регламентным заданием.

Эффект:

Снята постоянная пиковая нагрузка на сервер.

4. Формирование автоматических перемещений — запрос в цикле.

Что нашли:
Тяжелый запрос выполнялся столько раз, сколько было пар «Склад-отправитель : Склад-получатель».

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

Эффект:

Время формирования перемещений сокращено кратно количеству складов.

5. Взаиморасчеты — цикл с точкой (получение реквизитов).

Что нашли:
В алгоритме расчета задолженности для одного партнера 16 000 раз выполнялось получение реквизитов через точку.

Решение:
Получение представления заказа клиента и валюты перенесено в запрос.

Эффект:

Блокировки на регистре расчетов практически исчезли.

6. Помощник продаж — множественные серверные вызовы.

Что нашли:
При смене контрагента выполнялось 4 независимых серверных вызова вместо одного.

Решение:
Серверные вызовы объединены.

Эффект:

Среднее время смены контрагента снижено с 8 секунд до 2,2 секунды.

7. Полнотекстовый поиск в регистре «Товары организаций».

Что нашли:
Пользователи искали товары через полнотекстовый поиск, формируя запросы с условием «ПОДОБНО %болт%», которые попадали в топ длительных запросов.

Решение:
Обучение пользователей: поиск по колонке (Alt+F) вместо полнотекстового.

Эффект:

Поиск стал моментальным, тяжелые запросы ушли из монитора.

8. Разбор прайсов виртуального склада — запрос в цикле.

Что нашли:
Данные, необходимые в цикле, запрашивались многократно.

Решение:
Данные получены одним запросом и размещены в индексированной таблице значений.

Эффект:

Цикл ускорен, нагрузка на СУБД снижена.

Побочные эффекты: то, чего не планировали, но получили

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

1. Ошибка в расчете бонусов на 40 000 рублей в месяц
При анализе замера производительности перед записью реализации мы обратили внимание на тяжелый запрос расчета бонусов. В ходе оптимизации запроса выяснилось, что алгоритм работал неверно с 2017 года. Ежемесячные потери клиента составляли около 40 000 рублей из-за излишне начисленных бонусов. Ошибка была исправлена.

2. Ускорение интерфейса в 3,6 раза (8 сек → 2,2 сек)
Оптимизация помощника продаж не только повысила APDEX, но и кардинально улучшила удобство использования для менеджеров по продажам — самой массовой группы пользователей.

3. Обнаружена критическая ошибка администрирования MS SQL
В процессе мониторинга мы выяснили, что шаг авторасширения файла лога базы данных был установлен почти в 1 Тб. Это приводило к тому, что база «замирала» на несколько секунд в момент расширения, а место на диске заканчивалось мгновенно. После настройки корректного шага проблема исчезла.

Результаты

Первый этап

Прекратились ежедневные блокировки на регистре расчетов.
Перестало заканчиваться место на диске (после настройки авторасширения лога).
APDEX вырос с 0,45 до 0,55.

Второй этап

После устранения «тяжелых» запросов (особенно с условием «не равно» по полю качества бренда, которые вызывали свопирование rphost) и исправления множественных серверных вызовов:

APDEX достиг 0,8 — целевой показатель, соответствующий оценке пользователей «хорошо».
Время ключевых операций: проведение документа — сокращено в среднем на 40–60%; смена контрагента в помощнике продаж — с 8 до 2,2 секунды.
Поиск товаров — стал мгновенным после перехода на поиск по колонке.
Блокировки — полностью устранены на регистре расчетов, единичные случаи перестали влиять на работу пользователей.
Стабильность сервера — прекратились экстренные остановки служб, перестал заканчиваться диск, утилизация tempdb пришла в норму.

Бизнес-результат

Помимо технических метрик, клиент получил:

Прозрачную систему мониторинга производительности (APDEX + Технологический журнал), которая позволяет заранее видеть ухудшения.
Исправленную ошибку в бонусах — экономия 40 000 рублей в месяц.
Уверенность в том, что система выдержит дальнейший рост объемов и количества пользователей.