Оптимизация расчета себестоимости выпуска продукции (УПП 1.3, Партионный учет)
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Хорошая статья, спасибо, единственное, что при создании фоновых задач можно управлять стеком указывая ключ задания, который в данном случае будет являться именем регистра. 1С при запуске смотрит, нет ли задач с таким же ключем и только тогда запускает, а так же что это можно было оформить в конфигурацию в качестве модулей с такими же наименованиями, а не текстовыми файликами, а в целом мне очень актуально, больше всего занимает процесс записи у нас при расчете. Спасибо за то, что поделились.
(6) lunjio,
В этом случае сразу вывалится исключение что задание с таким ключём уже существует.
Если же предварительно запускать ожидание завершения фонового задания с этим ключем, тогда будет тормозиться основной поток - теряется смысл асинхронной записи.
Более того, даже после завершения, фоновое задание продолжает некоторое время висеть в памяти и соответственно не позволит запустить другое с таким же ключем.
Если вы внимательно просмотрите код, то увидите, что у меня все задания по одному регистру запускаются с именем этого регистра в наименовании, и уже внутри фонового задания происходит ожидание завершения предыдущих с таким же наименованием.
(Ключ задания - должен быть уникальным, Наименование задания - может быть любым)
Ок, во вложенный архив добавлен cf
единственное, что при создании фоновых задач можно управлять стеком указывая ключ задания, который в данном случае будет являться именем регистра. 1С при запуске смотрит, нет ли задач с таким же ключем и только тогда запускает
В этом случае сразу вывалится исключение что задание с таким ключём уже существует.
Если же предварительно запускать ожидание завершения фонового задания с этим ключем, тогда будет тормозиться основной поток - теряется смысл асинхронной записи.
Более того, даже после завершения, фоновое задание продолжает некоторое время висеть в памяти и соответственно не позволит запустить другое с таким же ключем.
Если вы внимательно просмотрите код, то увидите, что у меня все задания по одному регистру запускаются с именем этого регистра в наименовании, и уже внутри фонового задания происходит ожидание завершения предыдущих с таким же наименованием.
(Ключ задания - должен быть уникальным, Наименование задания - может быть любым)
а так же что это можно было оформить в конфигурацию в качестве модулей с такими же наименованиями, а не текстовыми файликами,
Ок, во вложенный архив добавлен cf
(7)
Вынужден с вами не согласиться, лично для интереса проверил следующим образом - создал регламентное задание которое в качестве параметра принимает ссылку на некий справочник, далее в цикле с 10 тыс. итерациями в специально созданный регистр сведений записываю данную ссылку с измерением равным счетчику цикла, для тестов достаточно. Создаю подряд два регламентных задания, с одинаковым ключом, в оба передаю разные значения ссылок, записываю их подряд, выполнится должны почти сразу после записи, ставлю точку останова в процедуре выполнения фонового задания, в другом сеансе вижу, что одно задание выполняется, второе ещё не выполнялось и не запускалось, как только отпускаю точку останова, попадаю туда сразу второй раз, в консоли регламентных заданий вижу что теперь второе задание исполняется, первое выполнено.
А чтобы регламентные задания не висели впустую, в фоновом задании их можно просто удалять.
У себя ещё не внедрил, но деньги за это думаю просите обосновано, грамотно проделанная оптимизация, ещё раз спасибо за публикацию.
Вынужден с вами не согласиться, лично для интереса проверил следующим образом - создал регламентное задание которое в качестве параметра принимает ссылку на некий справочник, далее в цикле с 10 тыс. итерациями в специально созданный регистр сведений записываю данную ссылку с измерением равным счетчику цикла, для тестов достаточно. Создаю подряд два регламентных задания, с одинаковым ключом, в оба передаю разные значения ссылок, записываю их подряд, выполнится должны почти сразу после записи, ставлю точку останова в процедуре выполнения фонового задания, в другом сеансе вижу, что одно задание выполняется, второе ещё не выполнялось и не запускалось, как только отпускаю точку останова, попадаю туда сразу второй раз, в консоли регламентных заданий вижу что теперь второе задание исполняется, первое выполнено.
А чтобы регламентные задания не висели впустую, в фоновом задании их можно просто удалять.
У себя ещё не внедрил, но деньги за это думаю просите обосновано, грамотно проделанная оптимизация, ещё раз спасибо за публикацию.
(13) lunjio,
Верно. Для Регламентного задания уникальность ключа не требуется. По Вашему предложению тоже можно организовать выполнение Фоновых заданий в стеке. Но все же получается сложновато - в этом случае для запуска Фоновых заданий дополнительно придется создавать, записывать в базу и удалять объекты Регламентных заданий. К тому же основное назначение Регламентных заданий - выполнение Фоновых задач по расписанию. Спасибо за подсказку, возможно, где нибудь пригодится.
Вынужден с вами не согласиться, лично для интереса проверил следующим образом - создал регламентное задание которое в качестве параметра принимает ссылку на некий справочник, далее в цикле с 10 тыс. итерациями в специально созданный регистр сведений записываю данную ссылку с измерением равным счетчику цикла, для тестов достаточно. Создаю подряд два регламентных задания, с одинаковым ключом, в оба передаю разные значения ссылок, записываю их подряд, выполнится должны почти сразу после записи, ставлю точку останова в процедуре выполнения фонового задания, в другом сеансе вижу, что одно задание выполняется, второе ещё не выполнялось и не запускалось, как только отпускаю точку останова, попадаю туда сразу второй раз, в консоли регламентных заданий вижу что теперь второе задание исполняется, первое выполнено.
А чтобы регламентные задания не висели впустую, в фоновом задании их можно просто удалять.
А чтобы регламентные задания не висели впустую, в фоновом задании их можно просто удалять.
Верно. Для Регламентного задания уникальность ключа не требуется. По Вашему предложению тоже можно организовать выполнение Фоновых заданий в стеке. Но все же получается сложновато - в этом случае для запуска Фоновых заданий дополнительно придется создавать, записывать в базу и удалять объекты Регламентных заданий. К тому же основное назначение Регламентных заданий - выполнение Фоновых задач по расписанию. Спасибо за подсказку, возможно, где нибудь пригодится.
(16)
Да согласен, в вашем варианте более оптимально, как-то сразу не подумал, притом что если организовывать через регламентные, встает проблема с ожиданием завершения всех текущих заданий, в голове рисуется что ожидание будет не очень красивым в плане кода и логики ,в важем случае все четко, НО внесу свои две копеек всё-таки в оптимизацию кода
Текст где в процедуре фонового задания мы ожидаем завершения предыдущих в стеке, нужно перенести в начало процедуры, не совсем оптимально по отношению к памяти, создаем набор записи, переносим в него таблицу, а потом ждём.
Да согласен, в вашем варианте более оптимально, как-то сразу не подумал, притом что если организовывать через регламентные, встает проблема с ожиданием завершения всех текущих заданий, в голове рисуется что ожидание будет не очень красивым в плане кода и логики ,в важем случае все четко, НО внесу свои две копеек всё-таки в оптимизацию кода
Текст где в процедуре фонового задания мы ожидаем завершения предыдущих в стеке, нужно перенести в начало процедуры, не совсем оптимально по отношению к памяти, создаем набор записи, переносим в него таблицу, а потом ждём.
(18) lunjio,
Зато оптимально в плане скорости, после окончания ожидания уже всё готово, остается только записать набор записей. Спорный момент. Зависит от приоритетов в конкретной реализации.
НО внесу свои две копеек всё-таки в оптимизацию кода
Текст где в процедуре фонового задания мы ожидаем завершения предыдущих в стеке, нужно перенести в начало процедуры, не совсем оптимально по отношению к памяти, создаем набор записи, переносим в него таблицу, а потом ждём.
Текст где в процедуре фонового задания мы ожидаем завершения предыдущих в стеке, нужно перенести в начало процедуры, не совсем оптимально по отношению к памяти, создаем набор записи, переносим в него таблицу, а потом ждём.
Зато оптимально в плане скорости, после окончания ожидания уже всё готово, остается только записать набор записей. Спорный момент. Зависит от приоритетов в конкретной реализации.
Большое спасибо Вам за идею! Хотелось бы задать пару вопросов: не совсем понимаю зачем мы предварительно выгружаем набор записей в таблицу значений ПараметрыЗадания.Добавить(НаборЗаписей.Выгрузить()) (на это же тратится дополнительное время)? Почему нельзя просто передать НаборЗаписей в фоновое задание и там выполнить метод НаборЗаписейЗадания.Записать(Замещение)? Так же не совсем понимаю почему для регистра накопления используется вызов промежуточного метода: ОбщегоНазначения.ВыполнитьДвижениеПоРегистру(НаборЗаписейЗадания) ? Разве строки НаборЗаписейЗадания.Загрузить(ТаблицаДвижений); будет недостаточно? Заранее благодарю за ответ!
(8) anama_agro,
Пробовал, надеялся, но ругается на мутабельность значения.
Данный участок кода позаимствован из типового. В этом методе при копировании ТаблицыЗначений в НаборЗаписей отсекаются пустые ссылки и пустые значения в случае, если реквизит составного типа. Что благотворно сказывается на самочувствии регистра накопления.
не совсем понимаю зачем мы предварительно выгружаем набор записей в таблицу значений ПараметрыЗадания.Добавить(НаборЗаписей.Выгрузить()) (на это же тратится дополнительное время)? Почему нельзя просто передать НаборЗаписей в фоновое задание и там выполнить метод НаборЗаписейЗадания.Записать(Замещение)?
Пробовал, надеялся, но ругается на мутабельность значения.
Так же не совсем понимаю почему для регистра накопления используется вызов промежуточного метода: ОбщегоНазначения.ВыполнитьДвижениеПоРегистру(НаборЗаписейЗадания) ? Разве строки НаборЗаписейЗадания.Загрузить(ТаблицаДвижений); будет недостаточно?
Данный участок кода позаимствован из типового. В этом методе при копировании ТаблицыЗначений в НаборЗаписей отсекаются пустые ссылки и пустые значения в случае, если реквизит составного типа. Что благотворно сказывается на самочувствии регистра накопления.
(10) sarun,
Действительно, есть ошибочка, выложил исправленный cf
(у нас не задействован управленческий учет, поэтому ошибка не проявлялась)
{ОбщийМодуль.ПроцедурыРасчетаБазыРаспределенияЗатрат.Модуль(2200)}: Ошибка при вызове метода контекста (Выполнить)
РезультатЗапроса = Запрос.Выполнить();
по причине:
{(103, 1)}: Синтаксическая ошибка
РезультатЗапроса = Запрос.Выполнить();
по причине:
{(103, 1)}: Синтаксическая ошибка
Действительно, есть ошибочка, выложил исправленный cf
(у нас не задействован управленческий учет, поэтому ошибка не проявлялась)
(14) sarun,
Эффект ускорения проведения возникает не при большом размере базы, а при большом количестве выпускаемой номенклатуры в месяц и большом количестве затрат.
У нас недавно был апгрейд железа. После чего время проведения стало следующим: без доработок - 8 часов, с доработками не асинхронно - 5 часов, асинхронно - 3,5 часа.
Ну и без доработок размер tempdb по прежнему зашкаливает.
Количество записей в регистрах нашего документа (один месяц):
РегистрНакопления.ВыпускПродукцииБухгалтерскийУчет: 46 136
РегистрНакопления.ВыпускПродукцииНалоговыйУчет: 46 136
РегистрНакопления.НезавершенноеПроизводствоБухгалтерскийУчет: 324 521
РегистрНакопления.НезавершенноеПроизводствоНалоговыйУчет: 324 445
РегистрНакопления.ЗатратыНаВыпускПродукцииБухгалтерскийУчет: 2 646 298
РегистрНакопления.ЗатратыНаВыпускПродукцииНалоговыйУчет: 2 646 297
при обычной (не асинхронной записи) в регистры выигрыша в скорости не заметил. УПП 1.3.81.2, по переделам, партионный учет, база 50 Гб.
Эффект ускорения проведения возникает не при большом размере базы, а при большом количестве выпускаемой номенклатуры в месяц и большом количестве затрат.
У нас недавно был апгрейд железа. После чего время проведения стало следующим: без доработок - 8 часов, с доработками не асинхронно - 5 часов, асинхронно - 3,5 часа.
Ну и без доработок размер tempdb по прежнему зашкаливает.
Количество записей в регистрах нашего документа (один месяц):
РегистрНакопления.ВыпускПродукцииБухгалтерскийУчет: 46 136
РегистрНакопления.ВыпускПродукцииНалоговыйУчет: 46 136
РегистрНакопления.НезавершенноеПроизводствоБухгалтерскийУчет: 324 521
РегистрНакопления.НезавершенноеПроизводствоНалоговыйУчет: 324 445
РегистрНакопления.ЗатратыНаВыпускПродукцииБухгалтерскийУчет: 2 646 298
РегистрНакопления.ЗатратыНаВыпускПродукцииНалоговыйУчет: 2 646 297
Вопросы с вознаграждением
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|