Приблизительный план при расследовании проблем производительности для базы 1С в режиме клиент-сервера:
Фиксация проблемы
Перед расследованием проблем производительности необходимо зафиксировать наличие данной проблемы. Для этого надо, чтобы пользователь продемонстрировал зависания. Важно помнить, что некоторые вещи, например отчет по валовой прибыли крупного производственного предприятия за год, не могут выполняться за одну секунду.
Загрузка оборудования
Необходимо выяснить, насколько загружено оборудование, хватает ли процессора, оперативной памяти и жесткого диска. Если в системе один процесс rphost, много процессорных ядер и много пользователей, то имеет смысл уменьшить количество соединений на процесс в настройках кластера. В большинстве случаев загрузка оборудования не причина, а следствие зависания. Как правило, причина кроется в неоптимальном коде и апгрейд сервера позволяет лишь на короткое время увеличить производительность.
Неоптимальный код
Главная проблема производительности — неоптимальный код. Именно оптимизация кода может увеличить скорость в разы и десятки раз. Как правило, код типовых конфигураций достаточно оптимален, поэтому лучше всего сделать сравнение с типовой конфигурацией и обратить внимание на доработанные участки.
Динамические списки
При необдуманном изменении запроса для динамического списка, производительность может резко деградировать. Запрос должен быть максимально простым. Неоптимальный запрос в динамическом списке в сочетании с механизмом РЛС может ухудшить не только производительность списка, но и общую производительность всей системы.
Ошибки 1С
Обязательно проверить журнал регистрации 1С, возможно есть ошибки, которые укажут проблемный кусок кода.
Выяснить на каких физических серверах находятся сервер SQL и сервер 1С
Если находятся на разных, то возможна задержка из-за сетевого взаимодействия между двумя физическими серверами. В идеале, чтобы находились на одном физическом сервере, если у этого сервера нет проблем с производительностью.
Для MS SQL проверить настройку и выполнение регламентных процедур
Необходимо проверить, запущен ли агент сервера SQL, настроены ли планы обслуживания и посмотреть логи, нет ли там ошибок. Обязательно должна быть дефрагментация индексов, реже индекс должен полностью перестраиваться. Обновление статистики важно, особенно на больших базах. Если обновление статистики не успевает выполнится за отведенное время, то MS SQL позволяет выполнять обновление статистики для определенных таблиц.
Права пользователей
Необходимо проверить зависания под разными пользователями. Механизм РЛС, наложенный на пользователя, может значительно снизить производительность. При этом под полноправным пользователем все будет работать достаточно быстро.
Проблема блокировок
Если при одном пользователе в базе все работает быстро, а при входе нескольких десятков/сотен/тысяч пользователей начинает все зависать, то вполне возможно, что проблема в блокировках. Для расследования проблем блокировок проще всего использовать технологический журнал.
Пересчет итогов
Важная процедура, которую обычно все пытаются избежать. В итоге, для расчета, например, остатков товара, документ при проведении берет последние рассчитанные остатки и складывает со всеми движениями, произведенными после расчета остатков.
Замеры производительности в конфигураторе
В конфигураторе есть возможность замера времени выполнения каждой строки кода. Данный метод хорош в случае, если проблема стабильно моделируется в однопользовательском режиме. Данный способ не показывает некоторые процедуры, например, обновление динамического списка. Так же важно, чтобы для сервера 1С был установлен режим отладки.
Много пользователей
Если в базе одновременно работает более 1000 пользователей, то возможны проблемы при ожидании на блокировках страницы. Дело в том, что СУБД хранит данные в страницах небольшого объема, по умолчанию 8 Кб, при записи эта страница полностью блокируется. Ожидание можно отследить с помощью счетчиков производительности Windows.
Клиент-серверное взаимодействие
При программировании формы необходимо учитывать, что при вызове серверных процедур и функций, на сторону сервера уходит описание формы. При возвращении управления на сторону клиента происходит обратная передача.
Из опыта — оптимизировал заполнение формы, которое выполнялось порядка одной минуты и зависало именно при завершении серверной функции, в которой заполнялась большая таблица. Помогло изменение контекстной функции на внеконтекстную и передача данных через хранилище значений. После оптимизации заполнение выполнялось порядка 15 секунд и не деградировало при увеличении количества данных.