Всем привет. Есть конфигурация на опер. учете. Проведение по критичным регистрам переписано на прямые запросы. В итоге время проведения 1 документа "задним" числом уменьшилось с 1 минуты до 12-13 секунд. Хочется еще ускорить, возможно ли и в какую сторону копать?

"Проведение по критичным регистрам переписано на прямые запросы." — интересно, как это сделано?

Забыл добавить. Если документ проводится 1-й раз, время 12-13 секунд, если повторно перепровести этот же документ, то он проводится за 1 секунду.

(1) 1cpp

(1) имеется ввиду заменен вызов ВыгрузитьИтоги() на выборку прямым запросом.

"Хочется еще ускорить, возможно ли и в какую сторону копать?" — а откуда уверенность, что можно еще быстрее сделать?

(5) см. (2)

(6) Вероятно, первый раз создаются записи в таблице, а при повторной записи анализируется, что ничего не изменилось и ничего не делается.

(6) так запрос кэшируется вот и быстрее.

1с это много

1 сек

(0) если уверен, что запрос написан грамотно, то можно еще
покопать в сторону добавлений индексов. но с ними тоже не стоит перебарщивать, это как раз тот случай когда кашу можно испортить маслом.

Снова - много лишних записей.
Убить нулевые итоги.

Проблемы с сетью
работа в локалке а не втерминале
и прочее

(12) Нет там нулевых итогов. Я базу только развернул на SQL. А насколько мне известно при выгрузке-загрузке итоги пересчитываются.

(13) Все и так в терминале.

сам запрос то на вт слеплен поди, да ?

ускорить можно
1.сделать период хранения останков 5 дней
2. налепить индексы на измерения
3. переписать алгоритмы проведения

(15) ага на них самых.

(15) лучше самому соединять, без ВТ?

(18) да нет, просто смотреть план запроса и..оптимизировать.
Только вот, как правило, получение итогов при проведении, это маааааленькая часть всего алгоритма проведения дока.

(19) Что переписывать в алгоритмах, если самая долгая операция (98%) это ВыполнитьИнструкцию() в прямом запросе.

(16) А каким образом индексы на измерения налепить? Подскажите где можно подсмотреть.

в пофигураторе, первое, поставить индекс на табличку движений воткнув галку быстрая обработка движений..
потом, можно понавтыкать галок (только не бездумно) на отбор итогов и движений на нужные измерения

(21) Спасибо за советы, попробую ускорить процесс

Все таки видимо проблема в алгоритме. Если делаю выборку по одной строке документа, отрабатывает быстро ~50мс. В плане запросов посмотрел, поиск только по индексам. Вообщем круто и быстро работает.

Проблема в том, что в расходных документах по 500-700 строк и строки могут дублироваться. А расчитывать остатки мне необходимо с учетом уже сформированных движений, поэтому приходится вызывать запрос 500-700 раз (для каждой строки). Отсюда долгое время общего проведения документа.

Что ж за непруха то такая.

(23) За это на экзамене выгоняют или даже заставляют писать тиражные рарусовские конфы.

Не надо каждую строку проводить, исправляй это. Свёртку ТЧ придумали давно, не игнорируй её.

(24) Ну тогда пусть 1с своих программистов повыгоняет с работы. Так типовой алгоритм работает. Да и ТЧ в общем случае не получится свернуть.

(15) Где это так проводятся документы? Старая методика была посчитать, чтоб не в ммнус, провести. Новая - провести, проверить минусы, откатить. Но чтоб цикл проведения по строкам  - сомневаюсь я.

Что за конфа?

(26) Не цикл проведения по строкам, а учет при расчете остатка уже сформированных движений документа. Конфигурация ТиС ред. 9.2.

(23) Запрос делай один раз и выгружай в ТЗ, потом по ходу проведения сразу меняй ТЗ с учетом уже сделанных движений.
В итоге на каждую строку будешь в ТЗ иметь актуальные данные.
Классика...