Есть фраза, которую в 1С-сопровождении слышали почти все:
“1С тормозит”.
Фраза короткая, эмоциональная и почти бесполезная для диагностики.
Что именно тормозит?
- форма открывается 15 секунд;
- документ записывается минуту;
- отчет строится полчаса;
- регламентное задание не успевает завершиться ночью;
- список подвисает при отборе;
- пользователи ждут проведения;
- интеграция забирает весь сервер;
- один документ блокирует работу отдела;
- после обновления “всё стало медленнее”;
- на тестовой базе быстро, на рабочей — боль.
Для пользователя всё это может называться одинаково: “тормозит”.
Для разработчика и администратора это совершенно разные задачи.
В этой статье разберем практичный подход к диагностике производительности 1С: как перейти от общей жалобы к измеримой проблеме, где искать узкие места, какие уровни проверять и почему “сразу полезть оптимизировать запрос” — не всегда лучший первый шаг.
Сразу оговорюсь: здесь не будет волшебной кнопки “ускорить 1С”. Производительность — это не магия и не шаманство с бубном. Это нормальная инженерная работа: замерили, нашли узкое место, проверили гипотезу, исправили, снова замерили.
“Медленно” — это не метрика
Главная ошибка в диагностике производительности — начинать оптимизацию до того, как стало понятно, что именно измеряем.
Пользователь говорит:
“Документы долго открываются”.
Но для диагностики этого мало. Нужно уточнить:
- какой именно документ;
- какая форма;
- какой пользователь;
- какая база;
- какой период;
- сколько секунд открывается;
- всегда или иногда;
- у всех или у одного пользователя;
- после какого действия стало хуже;
- что считается нормой.
Одна и та же жалоба может вести к разным причинам.
| Жалоба | Что нужно уточнить | Возможная причина |
|---|---|---|
| Форма долго открывается | Сколько секунд, какая форма, у кого | Динамический список, запросы при открытии, лишнее заполнение реквизитов |
| Документ долго записывается | Запись или проведение, какие данные, какой объем | Подписки, проверки, движения, блокировки, тяжелые запросы |
| Отчет долго строится | Период, отборы, количество строк, настройки | СКД, запрос, временные таблицы, отсутствие ограничений |
| Все зависает утром | Время, пользователи, фоновые задания | Регламентные задания, блокировки, нагрузка на сервер |
| После обновления стало хуже | Что обновляли, какие сценарии изменились | Изменение типового кода, расширения, новые проверки, измененный запрос |
Пока нет измерения, у команды нет задачи по производительности. Есть только ощущение.
Первый шаг оптимизации — не исправление кода, а превращение жалобы в измеримую проблему.
От жалобы к замеру
Хорошая формулировка проблемы звучит не так:
“Форма тормозит”.
А так:
“Форма списка внутренних документов у пользователей отдела согласования открывается 18–25 секунд при отборе за текущий год. Ожидаемое время — до 5 секунд. Проблема воспроизводится на рабочей базе, на тестовой базе с меньшим объемом данных открывается за 3 секунды”.
Разница огромная.
Во втором варианте уже есть:
- конкретный сценарий;
- пользователи;
- время выполнения;
- ожидаемый результат;
- условия воспроизведения;
- первичная гипотеза про объем данных.
Вот с такой задачей можно работать.
Что измерять в 1С
Для большинства задач по производительности полезно фиксировать несколько базовых показателей.
| Показатель | Зачем нужен |
|---|---|
| Время открытия формы | Понять, где пользователь реально ждет |
| Время выполнения команды | Измерить конкретное действие, а не “всё медленно” |
| Время записи / проведения | Отделить проблемы формы от проблем бизнес-логики |
| Время выполнения запроса | Найти тяжелые выборки и отчеты |
| Количество строк | Понять, не пытаемся ли обработать слишком большой объем |
| Количество обращений к серверу | Увидеть лишние серверные вызовы из формы |
| Количество повторных операций | Найти циклы и повторяющиеся запросы |
| Длительность фонового задания | Понять, укладывается ли оно в свое окно выполнения |
| Количество ошибок и блокировок | Отделить “медленно” от “ждет освобождения ресурса” |
Иногда достаточно простого замера через начало и конец операции.
Иногда нужен технологический журнал, анализ запросов, журнал регистрации, замеры на сервере, сравнение с тестовой базой или профилирование конкретного участка.
Но начинать всё равно стоит с простого вопроса:
“Какое действие, сколько секунд, в каких условиях?”
Семь уровней диагностики производительности
Когда пользователь говорит “1С тормозит”, удобно не бросаться сразу в код, а пройтись по уровням.
Я бы выделил семь уровней:
- пользовательский сценарий;
- клиент и рабочее место;
- форма и интерфейс;
- запросы и отчеты;
- серверная бизнес-логика;
- база данных и блокировки;
- фоновые и регламентные процессы.
Такой подход помогает не лечить не ту болезнь.
Уровень 1. Пользовательский сценарий
Начинаем не с кода, а со сценария.
Нужно понять:
- какое действие выполняет пользователь;
- какой результат ожидает;
- сколько сейчас занимает действие;
- сколько должно занимать;
- как часто выполняется операция;
- сколько пользователей с этим сталкиваются;
- какой бизнес-процесс страдает.
Почему это важно?
Потому что не все тормоза одинаково важны.
Если отчет для аналитика строится 7 минут раз в месяц — это одна задача.
Если форма согласования открывается 20 секунд у 50 пользователей каждый день — это совсем другая задача.
Если проведение документа блокирует работу отдела продаж — это уже критичный инцидент.
Перед оптимизацией полезно оценить не только техническое время, но и цену ожидания.
Уровень 2. Клиент и рабочее место
Иногда проблема не в запросе и не в сервере.
Бывает, что тормозит:
- конкретный компьютер;
- тонкий клиент;
- сетевое подключение;
- удаленный доступ;
- антивирус;
- локальные настройки;
- канал до сервера;
- работа через VPN;
- печать или открытие файлов;
- внешняя компонента.
Простой тест:
- выполнить тот же сценарий под тем же пользователем на другом рабочем месте;
- выполнить сценарий под другим пользователем на этом же рабочем месте;
- сравнить толстый/тонкий клиент, если это применимо;
- проверить, повторяется ли проблема на сервере или только у клиента.
Если у одного пользователя форма открывается 30 секунд, а у остальных 4 секунды, рано переписывать запрос.
Уровень 3. Форма и интерфейс
В управляемых формах много проблем производительности прячется не в “большом алгоритме”, а в мелочах:
- при открытии формы выполняется слишком много кода;
- динамический список тянет лишние поля;
- условное оформление перегружает форму;
- в обработчиках событий выполняются серверные вызовы;
- при изменении одного реквизита пересчитывается половина формы;
- табличная часть заполняется слишком большим объемом данных;
- форма получает данные, которые пользователь не видит;
- команды проверяют доступность слишком тяжелым способом;
- расширения добавили проверки при открытии;
- форма обращается к серверу в цикле.
Для диагностики формы полезно отдельно замерить:
- время создания формы;
- время выполнения ПриСозданииНаСервере;
- время заполнения данных;
- время выполнения запросов для списков;
- время после пользовательских действий;
- количество серверных вызовов.
Очень часто ускорение формы начинается с вопроса:
“А все ли данные, которые мы грузим при открытии, действительно нужны сразу?”
Уровень 4. Запросы и отчеты
Тяжелые запросы — классическая причина тормозов.
Но и здесь важно не гадать.
Плохой подход:
“Наверное, запрос тяжелый. Давайте его перепишем”.
Хороший подход:
- найти конкретный запрос;
- замерить время выполнения;
- понять объем данных;
- проверить отборы;
- посмотреть, какие соединения используются;
- проверить временные таблицы;
- посмотреть, нет ли лишних полей;
- сравнить выполнение на малом и большом периоде;
- проверить, не запускается ли запрос много раз в цикле.
Типовые проблемы запросов:
- нет ограничения периода;
- выбираются все поля “на всякий случай”;
- лишние соединения;
- неудачные условия соединения;
- сложные вычисления по большим наборам;
- обращение к виртуальным таблицам без нужных параметров;
- запрос выполняется для каждой строки отдельно;
- отчет пытается построить слишком подробную детализацию;
- СКД дает пользователю слишком широкие настройки без ограничений.
Иногда ускорение отчета — это не переписать запрос, а ограничить сценарий:
- обязательный период;
- разумный отбор по организации;
- отдельный режим “детально”;
- предварительный расчет;
- фоновые задания для тяжелых отчетов;
- кэширование промежуточных данных, если оно оправдано.
Уровень 5. Серверная бизнес-логика
Не вся медленная операция упирается в запрос.
Документ может долго записываться из-за:
- подписок на события;
- обработчиков ПередЗаписью и ПриЗаписи;
- дополнительных проверок;
- расширений;
- перезаполнения табличных частей;
- обращений к внешним сервисам;
- пересчета связанных объектов;
- формирования печатных форм;
- лишних запросов в цикле;
- записи дополнительных регистров;
- проверки прав нестандартным способом.
Здесь помогает разбиение операции на этапы.
Например, при проведении документа можно замерить:
- подготовку данных;
- проверки заполнения;
- запросы остатков;
- формирование движений;
- запись движений;
- постобработку;
- вызовы подписок;
- работу расширений.
Если операция занимает 40 секунд, а 32 секунды уходят на одну проверку, у нас появляется конкретная точка оптимизации.
Уровень 6. База данных и блокировки
Иногда пользователь говорит “медленно”, а на самом деле операция ждет.
Ждет блокировку.
Ждет завершения другой транзакции.
Ждет тяжелый запрос.
Ждет ресурс, который занял другой пользователь или регламентное задание.
Типовые признаки:
- операция иногда выполняется быстро, иногда очень долго;
- проблема возникает в определенное время;
- медленно только при параллельной работе пользователей;
- проведение документов “выстраивается в очередь”;
- регламентное задание мешает пользователям утром;
- при повторе через несколько минут всё быстро.
В таких случаях нужно смотреть не только код операции, но и конкуренцию за данные.
Здесь важны:
- длина транзакций;
- порядок записи объектов;
- объем данных в транзакции;
- параллельные задания;
- запросы внутри транзакций;
- массовые обработки в рабочее время;
- запись одних и тех же регистров;
- избыточные блокировки.
Если не отделить “медленно считает” от “ждет блокировку”, можно потратить много времени не туда.
Уровень 7. Фоновые и регламентные процессы
Фоновые задания часто остаются за кадром.
Пользователи видят только последствия:
- утром база тяжелая;
- отчеты строятся медленнее;
- обмены не успевают завершиться;
- очередь фоновых заданий растет;
- сервер занят непонятной нагрузкой;
- часть заданий падает и перезапускается;
- ночное окно обслуживания не укладывается во время.
Для диагностики нужно понимать:
- какие задания активны;
- когда они запускаются;
- сколько длятся;
- как часто падают;
- какие данные обрабатывают;
- конфликтуют ли с пользовательской работой;
- можно ли перенести тяжелые операции;
- нужно ли дробить обработку на порции.
Регламентное задание, которое работало нормально на базе в 50 тысяч объектов, может стать проблемой на базе в 5 миллионов объектов.
Производительность — это не только код. Это еще и расписание нагрузки.
Чек-лист диагностики медленной формы
Формы — одна из самых частых пользовательских жалоб.
Если форма открывается медленно, я бы шел по такому чек-листу.
| Шаг | Вопрос | Что проверить |
|---|---|---|
| 1 | Сколько секунд открывается форма? | Замерить фактическое время, а не полагаться на ощущение |
| 2 | У всех ли пользователей проблема? | Сравнить разных пользователей и разные рабочие места |
| 3 | Проблема в форме или в данных? | Открыть разные объекты, разные периоды, разные отборы |
| 4 | Что выполняется при открытии? | ПриСозданииНаСервере, заполнение реквизитов, проверки |
| 5 | Есть ли тяжелые динамические списки? | Отборы, поля, условное оформление, соединения |
| 6 | Есть ли лишние серверные вызовы? | Обработчики событий, команды, пересчеты |
| 7 | Влияют ли расширения? | Отключение на тесте, сравнение поведения |
| 8 | Можно ли отложить загрузку данных? | Загружать часть данных по кнопке или при открытии вкладки |
| 9 | Что изменилось недавно? | Релиз, обновление, новая проверка, новый реквизит, новая роль |
| 10 | Есть ли замер после исправления? | Сравнить было/стало на том же сценарии |
Типовые причины тормозов 1С
Если собрать частые причины в одну таблицу, получится такая картина.
| Причина | Как проявляется | Что делать |
|---|---|---|
| Тяжелый запрос | Отчет или форма долго получает данные | Замерить запрос, проверить отборы, поля, соединения |
| Запрос в цикле | Операция медленно растет с количеством строк | Переписать на пакетную обработку |
| Лишние данные на форме | Форма долго открывается | Загружать только нужное, часть данных отложить |
| Длинная транзакция | Пользователи ждут друг друга | Сократить транзакцию, убрать лишние действия внутри |
| Блокировки | То быстро, то очень медленно | Искать конкурирующие операции и порядок записи |
| Тяжелое регламентное задание | Просадки по расписанию | Перенести, дробить, ограничить объем |
| Расширение или подписка | После доработки операция стала медленнее | Измерить вклад расширения или подписки |
| Нет ограничения периода | Отчет собирает слишком много данных | Ввести обязательные отборы и сценарии детализации |
| Лишняя детализация | Отчет строит огромную таблицу | Разделить сводный и детальный режим |
| Накопленный техдолг | Много мелких доработок дают общий эффект | Планировать рефакторинг и замеры по критичным сценариям |
Почти все эти причины можно найти только через замеры.
На глаз обычно кажется, что “виноват запрос”. Но виноватым может оказаться обработчик формы, подписка, блокировка, объем данных или фоновое задание.
Как не надо оптимизировать
Есть несколько вредных подходов.
Анти-подход 1. Оптимизировать без замера
Разработчик переписывает код, но не знает, сколько было до и сколько стало после.
В итоге улучшение может быть реальным, незаметным или вообще отрицательным.
Анти-подход 2. Начинать с самого сложного
Иногда команда сразу лезет в технологический журнал, SQL, планы запросов и настройки сервера.
А потом выясняется, что пользователь открывал список без отбора за 8 лет.
Сначала — сценарий и простые проверки. Потом — глубокая диагностика.
Анти-подход 3. Лечить симптом, а не причину
Например, ускорили один отчет, но не ввели обязательные отборы. Через месяц он снова стал тяжелым, потому что данных стало больше.
Анти-подход 4. Не проверять влияние изменений
Оптимизация может сломать бизнес-логику.
Если переписали запрос, изменили отборы или убрали часть заполнения формы, нужно проверить не только скорость, но и корректность результата.
Анти-подход 5. Делать всё в рабочей базе
Опасные эксперименты с производительностью лучше проводить на тестовой копии, особенно если речь о массовых обработках, тяжелых отчетах, изменении запросов и фоновых заданиях.
Как оформить задачу на оптимизацию
Хорошая задача на производительность должна быть похожа не на жалобу, а на диагностическую карточку.
| Поле | Пример |
|---|---|
| Сценарий | Открытие формы списка внутренних документов |
| Пользователи | Отдел согласования, 12 человек |
| Фактическое время | 18–25 секунд |
| Ожидаемое время | До 5 секунд |
| Периодичность | Каждый рабочий день |
| Условия | Рабочая база, отбор за текущий год |
| Первичная гипотеза | Тяжелый динамический список или лишние данные при открытии |
| Что замерить | Открытие формы, запрос списка, серверные вызовы |
| Критерий успеха | Открытие до 5 секунд на том же сценарии |
| Риск | Не изменить состав отображаемых данных |
Такая задача понятна разработчику, тимлиду и заказчику.
Она не гарантирует мгновенное решение, но убирает хаос.
Что показывать бизнесу
Бизнесу не всегда нужно знать, что именно мы сделали в запросе или обработчике формы.
Но бизнесу важно понимать эффект.
Лучше говорить не только:
“Оптимизировали форму”.
А так:
“Форма согласования открывалась 18–25 секунд. После оптимизации открывается 4–6 секунд. Сценарий выполняют около 40 пользователей ежедневно. Убрали лишнюю загрузку данных при открытии и сократили время ожидания в основном рабочем процессе”.
Это уже язык пользы.
Для руководителя полезны:
- было / стало;
- какой процесс ускорили;
- сколько пользователей затронуто;
- как часто выполняется операция;
- какой риск сняли;
- что нужно сделать дальше.
Производительность — это не только про миллисекунды. Это про предсказуемость работы процесса.
APDEX и пользовательское восприятие
В некоторых командах для оценки пользовательского опыта используют APDEX — условный показатель удовлетворенности временем отклика.
Идея простая: заранее определить, какое время считается комфортным, какое терпимым, а какое плохим.
Например, для открытия формы:
| Время | Оценка | Комментарий |
|---|---|---|
| До 3 секунд | Комфортно | Пользователь почти не замечает ожидание |
| 3–10 секунд | Терпимо | Работать можно, но ожидание заметно |
| Больше 10 секунд | Плохо | Пользователь воспринимает систему как медленную |
Не обязательно внедрять полноценную систему метрик сразу.
Но полезно договориться хотя бы о простых порогах:
- сколько должна открываться критичная форма;
- сколько допустимо строить отчет;
- сколько может длиться проведение;
- какие операции можно выносить в фон;
- какие сценарии являются критичными для пользователей.
Без порогов спор о производительности превращается в “мне кажется”.
План улучшения производительности за 30 дней
Если в базе накопились жалобы на тормоза, не стоит пытаться “ускорить всё”.
Лучше сделать короткий практичный цикл.
Неделя 1. Собрать жалобы и выбрать сценарии
- Собрать 10–20 жалоб пользователей.
- Объединить похожие проблемы.
- Выбрать 3–5 самых болезненных сценариев.
- Зафиксировать фактическое время.
- Определить ожидаемое время.
Неделя 2. Провести первичную диагностику
- Разделить проблемы по уровням: форма, запрос, запись, блокировка, фоновые задания.
- Проверить воспроизводимость.
- Найти самые вероятные узкие места.
- Не трогать пока всё подряд.
Неделя 3. Исправить 1–2 самые выгодные проблемы
- Выбрать задачи с максимальным эффектом.
- Сделать изменения на тестовой базе.
- Проверить корректность результата.
- Сравнить было / стало.
Неделя 4. Закрепить процесс
- Оформить чек-лист диагностики.
- Добавить замеры в критичные места.
- Зафиксировать правила для тяжелых отчетов и форм.
- Сформировать следующий список оптимизаций.
Цель первого месяца — не идеальная производительность всей системы.
Цель — перестать искать тормоза вслепую и показать первые измеримые улучшения.
Минимальный стандарт производительности для команды
Чтобы проблемы не повторялись, команде полезно договориться о минимальных правилах.
- Любая жалоба на производительность переводится в конкретный сценарий.
- Для критичных сценариев фиксируется время “было”.
- Перед оптимизацией формируется гипотеза.
- После изменения фиксируется время “стало”.
- Тяжелые отчеты получают обязательные отборы.
- Массовые обработки не запускаются в рабочее время без согласования.
- Регламентные задания имеют понятное расписание и контроль длительности.
- Расширения и подписки оцениваются по влиянию на ключевые операции.
- Оптимизация не считается завершенной без проверки корректности результата.
- Самые частые тормоза попадают в backlog технического долга.
Это не сложная методология. Это обычная гигиена сопровождения.
Главный вывод
Производительность 1С не стоит диагностировать наугад.
Когда пользователь говорит “тормозит”, это еще не задача для разработчика. Это сигнал, который нужно превратить в измеримый сценарий:
- что именно выполняется;
- сколько занимает;
- у кого воспроизводится;
- какой результат ожидается;
- что изменилось;
- какой уровень системы может быть причиной.
Тормоза могут быть в форме, запросе, серверной логике, блокировках, фоновых заданиях, рабочем месте, настройках, расширениях или просто в слишком широком пользовательском сценарии.
Если сразу бросаться “оптимизировать код”, можно потратить время не туда.
Правильный порядок другой:
- сформулировать сценарий;
- измерить текущее время;
- локализовать уровень проблемы;
- проверить гипотезу;
- исправить;
- снова измерить;
- зафиксировать результат.
Так производительность перестает быть мистикой.
Она становится управляемым процессом.
Хорошая оптимизация — это не “кажется, стало быстрее”. Хорошая оптимизация — это “было 20 секунд, стало 5 секунд, сценарий тот же, результат корректный”.
Именно с этого начинается взрослая работа с производительностью 1С: не с героического переписывания всего подряд, а с нормальной диагностики, понятных замеров и честного “было / стало”.
Вступайте в нашу телеграмм-группу Инфостарт