Сначала найдите границу задержки
Менеджер открывает подбор, ищет артикул и переносит товар в заказ. Для него это одна операция, но задержки могут возникать в разных местах. Покупка сервера или изменение запроса без разделения этапов рискует не решить проблему. Ниже — диагностика именно подбора номенклатуры в УТ 11, а не формирования отчётов или проведения документов.
Короткий вывод
Измерьте отдельно открытие формы, поиск и добавление позиции. Затем проверьте связь задержки с ценами, остатками и настройками пользователя. Причину подтверждают повторяемый сценарий и технический замер, а не одно удачное открытие.
Названия команд и состав полей зависят от релиза УТ, платформы и доработок. Используйте доступные настройки вашей формы; если нужного переключателя нет, не ищите универсальную команду из чужой инструкции.
Три этапа вместо одного секундомера
Для каждого этапа определите одинаковые начало и конец: появление окна ещё не означает, что список загрузился и принимает ввод. Поиск по артикулу, части наименования и штрихкоду фиксируйте как разные сценарии. Сохраняйте точную строку поиска, способ подтверждения ввода, товар, характеристику, упаковку и количество. Не включайте в замер время, когда сотрудник выбирает товар глазами.
Отметьте первый вызов после входа и повторный вызов в том же сеансе. Повторите последовательность несколько раз, сохранив все значения. Более быстрый повтор может быть связан с кешированием или начальной загрузкой, но сам по себе не доказывает причину. Не очищайте кеши и не перезапускайте общий сервер ради «чистого» опыта.
Форма, цены и остатки: что сравнивать
Зафиксируйте исходный документ и его контекст: организацию, партнёра, соглашение, дату, склад, вид цены и валюту — если они участвуют в вашем сценарии. Форма подбора может получать не только список товаров, но и связанные данные. Скрытая колонка не гарантирует, что запрос за этими данными перестал выполняться.
Эксперименты с настройками выполняйте на изолированной актуальной копии. Сначала воспроизведите исходную задержку, затем меняйте только один параметр. Если релиз позволяет управлять показом цен или остатков, сравните варианты с этими данными и без них. Проверяйте не только скорость, но и состав результата.
- Цены. Сохраняйте одинаковые дату, соглашение, вид цены, валюту и упаковку. Если задержка появляется при заполнении строки, отдельно исследуйте получение цены и пересчёт скидок: это ещё не доказательство медленного поиска.
- Остатки. Уточните, что именно показывает форма: физическое наличие, свободный остаток или доступность с учётом обеспечения. Эти показатели нельзя сравнивать как одно и то же. Функции управления запасами УТ описаны в источниках ниже.
- Склады и отборы. Сравните один согласованный склад и исходный набор складов; узкую группу товаров и исходный отбор. Запишите количество найденных строк. Ускорение на меньшей выборке — повод исследовать запрос, а не основание навсегда скрыть нужный ассортимент.
Почему у одного менеджера быстрее
Сопоставьте сохранённые настройки формы, рабочее место, тип клиента, сетевой маршрут и контекст документа. Одинаковое название команды не делает два опыта одинаковыми. Сначала повторите сценарий с теми же параметрами, затем изучайте различия пользователей.
Роли и ограничения доступа на уровне записей (RLS) могут менять условия получения данных. Сравнение с администратором не является чистым тестом: ему может быть доступна другая выборка. Проверку разных наборов прав проводит уполномоченный специалист только на изолированной копии, с контролем объёма доступных данных. Не отключайте RLS и не выдавайте полные права в рабочей базе ради скорости.
Соберите версии расширений и историю изменений формы. На копии разработчик может сравнить исходный вариант с вариантом без конкретного расширения, предварительно проверив его зависимости. Отключать расширения в продакшене для эксперимента нельзя. Если копия не воспроизводит проблему, результат не переносится на рабочую базу автоматически.
Что измерить специалисту 1С
Показатели производительности платформы позволяют увидеть количество и длительность вызовов сервера, объём переданных и принятых данных. Снимайте их для каждого этапа отдельно, а не за весь сеанс. Много коротких вызовов и один длительный вызов требуют разных проверок; большой объём передачи также может объяснять часть ожидания.
Замер производительности связывает длительность и число выполнений со строками кода, различает клиентское и серверное выполнение. На копии специалист проверяет обработчики открытия формы, обновления списка и заполнения строки. Отладочный замер влияет на условия выполнения: его показатели нельзя без оговорок сравнивать с обычным пользовательским секундомером.
Если задержка уходит на сервер, нужен ограниченный сбор технологического журнала. Администратор согласует окно воспроизведения, события и фильтры для установленной версии платформы: вызовы, обращения к СУБД, ожидания и ошибки. Привяжите записи ко времени действия, сеансу и процессу. Журнал регистрации действий пользователей не заменяет такой анализ.
Не включайте запись всех событий надолго. Заранее задайте каталог, лимит хранения, контроль свободного места и порядок остановки сбора. Логи могут содержать тексты запросов и деловые данные: доступ ограничивают, передачу согласуют. Подробный сбор в рабочей среде допустим только по согласованному плану с контролем нагрузки.
Сопоставьте интервал задержки с запросами и ожиданиями СУБД, нагрузкой CPU, памятью и дисками, фоновыми заданиями. Не складывайте механически длительности вложенных вызовов: получится двойной учёт. Свободный CPU не исключает ожидания блокировки или ввода-вывода; длинный серверный вызов не доказывает, что виноват только SQL.
Как подтвердить причину и результат
В протоколе каждого опыта сохраняйте: этап, время начала, длительность, первый или повторный запуск, версии УТ и платформы, пользователя и права, настройки формы, контекст документа, товар, число строк результата и фоновую нагрузку. Рядом — показатели вызовов и ссылка на соответствующий фрагмент замера или журнала.
Сравнивайте серии в одинаковых условиях, отдельно для первого и повторных запусков. Оценивайте типичное время и разброс, а не только лучший результат. После изменения повторите исходный сценарий и проверьте корректность цены, доступности товара, количества и ограничений доступа. Быстрее, но с неверной ценой — не исправление.
До любых изменений подготовьте резервную копию и проверьте возможность восстановления. Изолируйте тестовую базу от рабочих обменов и отправок. Зафиксируйте её ресурсы, данные и фоновые задания: тихая копия на другом сервере не равна рабочему контуру. Изменения сначала проверяют на копии, затем согласуют внедрение и откат.
Что передать в WeProf
Для начала достаточно описания этапа задержки, версий, обезличенных настроек и протокола замеров. Не отправляйте пароли или выгрузку рабочей базы обычным письмом. Если медленно работает не только подбор, начните с [общего плана диагностики 1С](https://weprof.ru/blog/pochemu-1c-tormozit-diagnostika-prichin-plan-proverki); для формирования аналитики есть отдельный материал о [медленных отчётах](https://weprof.ru/blog/1c-dolgo-formiruet-otchety).
WeProf проводит [аудит 1С](https://weprof.ru/1c-audit/): сопоставляем работу формы, серверные вызовы, запросы и инфраструктуру, определяем проверяемую причину и план исправления. После внедрения можем взять [сопровождение 1С](https://weprof.ru/1c-support/). Работаем удалённо по РФ.
Полезные материалы 1С
- [Показатели производительности — вызовы сервера и объём данных](https://v8.1c.ru/platforma/pokazateli-proizvoditelnosti/)
- [Замер производительности — длительность и частота выполнения кода](https://v8.1c.ru/platforma/zamer-proizvoditelnosti/)
- [Технологический журнал — назначение и настройка сбора](https://v8.1c.ru/platforma/tehnologicheskiy-zhurnal/)
- [УТ: управление складом и запасами — остатки и обеспечение](https://v8.1c.ru/trade/upravlenie-skladom-i-zapasami/)
По теме статьи
Найдём, где задерживается подбор
Обсудим сценарий, данные для диагностики и безопасный порядок проверки. Удалённо по РФ.