Здравствуйте.
На предприятии используется ААА 5.1.05.08 (с доработками) на платформе 1С 8.3.7.2008 в клиент-серверном варианте в связке с SQL Server.
С недавнего времени пользователи заметили, что при создании нового заказ-наряда очень долго (около 20-30 секунд) происходит открытие его формы. Замер производительности показал, что все это время выполняется упомянутая в теме процедура "урвзфЗаказНарядЗаполнитьКэшВыполнениеРабот". При этом открытие формы уже записанного заказ-наряда осуществляется, как и положено, практически моментально.
После выполнения реиндексации таблиц ИБ штатными средствами (то есть через тестирование и исправление ИБ) проблема пропадает на несколько дней, однако затем снова дает о себе знать. Также стоит отметить, что ранее при той же самой программно-аппаратной конфигурации проблема не проявлялась. Одно из моих предположений состоит в том, что в базе был достигнут некоторый "критичный" предел объема данных. Только непонятно каких именно =)
Я понимаю, что сотрудники 1С-Рарус не оказывают консультаций по программированию и защищенная функция на то и защищенная, чтобы никто не знал как она работает, но все же попробую задать свой вопрос к разработчикам ААА: можно ли хотя бы в пределах допустимого узнать, что делает упомянутая процедура и какие таблицы теоретически могут влиять на время ее выполнения?
На предприятии используется ААА 5.1.05.08 (с доработками) на платформе 1С 8.3.7.2008 в клиент-серверном варианте в связке с SQL Server.
С недавнего времени пользователи заметили, что при создании нового заказ-наряда очень долго (около 20-30 секунд) происходит открытие его формы. Замер производительности показал, что все это время выполняется упомянутая в теме процедура "урвзфЗаказНарядЗаполнитьКэшВыполнениеРабот". При этом открытие формы уже записанного заказ-наряда осуществляется, как и положено, практически моментально.
После выполнения реиндексации таблиц ИБ штатными средствами (то есть через тестирование и исправление ИБ) проблема пропадает на несколько дней, однако затем снова дает о себе знать. Также стоит отметить, что ранее при той же самой программно-аппаратной конфигурации проблема не проявлялась. Одно из моих предположений состоит в том, что в базе был достигнут некоторый "критичный" предел объема данных. Только непонятно каких именно =)
Я понимаю, что сотрудники 1С-Рарус не оказывают консультаций по программированию и защищенная функция на то и защищенная, чтобы никто не знал как она работает, но все же попробую задать свой вопрос к разработчикам ААА: можно ли хотя бы в пределах допустимого узнать, что делает упомянутая процедура и какие таблицы теоретически могут влиять на время ее выполнения?
