Обновление для всех!
Еще больше возможностей, еще быстрее обработка, еще проще разработка - Универсальный менеджер потоков 2.0.
Полная версия, полностью открытый код и только за $m.
Данный материал переходит в разряд статьи
Очень кратко, о чем речь…
Фреймворк в виде одного общего модуля, позволяющего при получении объектов на обработку запускать их в несколько потоков. Особенности:
- Нет необходимости рассчитывать «порции» для обработки;
- Нет необходимости организовывать файловый обмен между потоками;
- Возможность запускать несколько менеджеров потоков одновременно, при этом потоки одного менеджера, могут запускать новые менеджеры со своими задачами и потоками (главное чтоб лицензий хватило :));
- Можно выстраивать граф зависимости объектов, что позволяет, например, избегать взаимоблокировок и/или организовать восстановление партий (на нашем предприятии удалось добиться 10х+ ускорения при 10 потоках в рабочее время – 200+ активных пользователей - Результаты работы механизма);
- Можно и нужно производить вмешательство в алгоритмы с помощью событий;
- Возможность описывать алгоритмы событий, как в модуле менеджера, так и в любом другом модуле БД (предпочтительно), а также во внешней обработке.
- Автоматический рестарт потока в случае ошибок;
- Контроль за количеством рестартов по каждому объекту;
- Возможность получать «ответы» от потоков;
- Возможность контролировать работу с помощью «Инструментов разработчика» или иных отчетов;
- Возможность срочного прерывания работы;
- И многое другое…
О том, как оно все работает описано ниже, при желании можно и свое написать :)
Буков очень много, но и картинок достаточно :)
Оглавление
Пример 1 (По складам - для восстановления партий не подходит)
Пример 2 (По складам - для восстановления партий подходит)
Пример 3 (По складам и номенклатуре - для восстановления партий не подходит)
Пример 4 (По складам и номенклатуре - для восстановления партий не подходит)
Пример 5 (По складам и номенклатуре - для восстановления партий подходит)
Пример 6 (Варианты на одном примере)
Обновление «Очереди для потоков»
Функция ПолучитьСтруктуруПараметровИнициализацииМенеджераПотоков()
Функция ИнициализироватьМенеджерПотоков()
Процедура «ОбработатьОбъект()»
Функция «ОбработатьСобытиеРазработчика()»
Месторасположение функции «ОбработатьСобытиеРазработчика()»
В общем модуле «МенеджераПотоков»
В произвольном модуле БД (рекомендуемый)
События функции «ОбработатьСобытиеРазработчика()»
Событие: «ПередЗапускомМенеджераПотоков»
Событие: «ПриЗапускеМенеджераПотоков»
Событие: «ПриПолученииМассиваРесурсов»
Событие: «ПриОбработкеИсключенийИзОчередиМенеджера»
Событие: «ПриОпределенииТипДанныхВПотоке»
Событие: «ПриОбработкеДействияПотока»
Событие: «ПриОбработкеОтветаПотока»
Событие: «ПриНевозможностиОбработатьОбъект»
Событие: «ПередЗавершениемМенеджераПотоков»
Событие: «ПослеЗавершенияМенеджераПотоков»
Событие: «ПриПолученииМестаХраненияФайловМониторинга»
Вариант передачи данных между событиями
Введение
В данной публикации будет максимально подробно «разжеван» способ реализации «Менеджера потоков», а так же предоставлены демо обработки с готовым открытым исходным кодом.
Описание и примеры с кодом, в данной статье, будут даны в общих чертах по принципу от общего к частному. На каких-то скринах будут отсутствовать параметры процедур и функций или строки кода, в связи с тем, что в данной конкретной теме это не является существенным.
Все повествование будет вестись на примере «Восстановления партий», т.к. эта задача была первоочередной, но в дальнейшем переродилась в «Универсальный механизм». «Универсальным» он назван по той причине, что общий модуль, где располагаются алгоритмы «Менеджера потоков» могут быть обособлены и не изменны на всем протяжении использования механизма, но при этом решать разные задачи (восстановление партий, расчет зарплаты, формирование пакетов документов, формирование отчетов и т.д.).
Весь код и в скринах, и в обработках написан на обычных формах, т.к. разработка велась на базе УПП. Описание предоставлено в рамках «Восстановления партий».
Но обо всем по порядку …
Результаты работы механизма
При распараллеливании на 10 потоков.
| Показатель | Ноябрь 2016 | Декабрь 2016 | Январь 2017 | Февраль 2017 |
|---|---|---|---|---|
| Документов в последовательности (шт.) | 22865 | 18298 | 14788 | 17189 |
| Документов для восстановления (шт.) | 14192 | 9252 | 8537 | 9921 |
| Однопоточное восстановление («холодный»/«прогретый») (мин.) | 293/265 | 215/196 | 172/162 | 219/203 |
| Параллельное восстановление («холодный»/«прогретый») (мин.) | 30/24 | 20/16 | 16/14 | 19/17 |
Здесь и далее под «холодный» и «прогреты» понимается запуск обработки сразу после восстановления БД («холодный») и запуск повторно («прогретый»).
Как проводились тесты:
- на копии продуктивной БД (УПП; 3 года; ~200 Гб; 1 организация);
- по 4 месяцам (ноябрь 2016, декабрь 2016, январь 2017, февраль 2017);
- копия БД восстанавливалась на момент перед первым восстановлением последовательности за период;
- по каждому месяцу было развёрнуто по 2 копии БД, в одной запускался типовое восстановление (без настроек обработки), в другой с использованием «Менеджера потоков»
Железо
Сервер 1С и Клиент
- Процессор: i7-3930K 3.2 ГГц;
- ОЗУ: 16Гб;
- ПЗУ: SSD KINGSTON SH103S3120G;
SQL Сервер
(продуктив: 1 продуктивная база; 15-18 баз разработчиков)
- Процессор: 2xXeon E5-2697v2 2.7 ГГц;
- ОЗУ: 128Гб;
- ПЗУ Система: RAID-1 2xSSD IBM System X 512Гб;
- ПЗУ База: SSD Intel P3700 800Гб (только приобрели – тестируем, обе тестируемые базы тут);
- ПЗУ Tempdb: RAID-10 4xSSD IBM System X 512Гб.
Программное обеспечение
Сервер 1С и Клиент
- Win 7 Prof SP1 64x
- 1С:Предприятие 8.3 (8.3.9.1850) 32x
SQL Сервер
- WinServer 2012 R2 Standard 64x
- SQL Server 2008 R2 (10.50.6000)
Предыстория
(кому не интересно могут смело идти дальше)
Мое основное рабочее место в крупной строительной организации. Часто бывает, что ближе к концу отчетному периоду начинают все интенсивнее приходить документы, включая те, что относятся к началу отчетного периода. И приходиться заново проводить восстановление партий и перезакрывать период. Все бы ни чего, но делать это в рабочее время не получается из-за блокировок. Приходится восстановление проводить по ночам, а период закрывать на следующий день и так по каждому месяцу до крайнего. В худшем случае может потребоваться 3 дня L.
Если месяц закрыт и все ошибки выверены, то на полное перезакрытие уходит около 5 часов, 3-4 из которых – это восстановление партий. В свою очередь восстановление партий - это всего лишь один этап при закрытии месяца, а всего их от 28 до 31 в зависимости от периода. При вопросе, что оптимизировать сомнений уже не осталось.
Я был знаком с механизмом фоновых заданий, но часто на практике его использовать не приходилось. Мне виделось решение проблемы именно тут, но как?
У нашей организации очень обширная география (от Сочи до Камчатки). В своем большинстве объекты обособленные. Склады и производство находятся в непосредственной близости друг к другу. Перемещения материалов между объектами происходят достаточно редко по сравнению поступлениями и списаниями на них. Тогда и появилась первая мысль «а нельзя ли восстанавливать последовательность в рамках объектов?».
Первая версия обработки в данном направлении была готова примерно через 2 недели (это был февраль 2016г.) и тогда показала неплохие результаты, партии восстанавливались примерно за 50 мин. Но у данной обработки были большие минусы:
- была не пригодна для общего использования (не у всех такая особенность учета складов и производства);
- достаточно много корректировок в типовом коде;
- достаточно сложна для понимания принципов работы при вычислении порции для потоков.
Как в жизни, если не получается или получается «не совсем удачно» - обратимся к мануалу :).
Хотелось большего выигрыша в скорости, что подвигло меня посмотреть, что по этому поводу пишут в интернете. Нашел интересные статьи:
- Ускорение восстановления последовательности документов в УПП. (Источник: http://www.forum.mista.ru/topic.php?id=541251&page=1); Это был первый источник, где можно было ознакомиться с мыслями сообщества по данному вопросу. Вы этой теме была найдена ссылка – след. пункт, на более глубокий теоретический подход к решению проблемы.
- Ускорение процесса восстановления последовательности в 1С 8 УПП с использованием параллельных вычислений (Источник: http://www.softpoint.ru/archive/article_id375.php); Достаточно подробно и в картинках – весьма познавательно.
- Параллельное восстановление партий (Источник: http://techlab.rarus.ru/news/articles/parallelnoe-vosstanovlenie-partiy/ ) Тут больше о достижении 1С-Рарус в решении данного вопроса, а также представлены результаты одного из заказчиков.
Это дало мне надежду, что можно найти еще более оптимальное решение. Но в связи с загрузкой на работе пришлось закинуть идею в дальний ящик, т.к. задачу решал на энтузиазме, а не по просьбе заказчика.
…
Снова вернуться к данной разработке меня подвигло появление свободного времени и любопытство. Еще раз ознакомившись с вышеописанными источниками решил поискать, о какой доработке типового УПП писал «1С-Рарус». Решил поискать «тормоза» типового решения. Кандидаты нашлись довольно быстро - это:
- Настройка в обработке «Восстановление партий» Меню – «Настройка» - «Настройка обработки» - «Ручная настройка» - «Количество документов в выборке». Данный параметр отвечает за количество итераций «Запрос в цикле». По умолчанию = 1, т.е. выполнение запроса на выборку 1 документа и так столько раз, сколько документов в обрабатываемом периоде последовательности.
- Процедура «СдвинутьПоследовательностьВперед()» в общем модуле «Заполнение документов» из которой вызывается функция «ОпределитьНеобходимостьСдвигаГраницы», что приводит нас, как и в первом случае к «Запросу в цикле».
- Не оптимально написанные запросы в общем модуле «УправлениеЗапасамиПартионныйУчет»:
- Процедура ЗаполнитьЗапросПартийНаСкладахУпр;
- Процедура ЗаполнитьЗапросПартийНаСкладахБух;
- Процедура ЗаполнитьЗапросПартийНаСкладахНал;
Последнее, скорее всего и есть тот самый «патч» :).
Все остальное было не столь существенно:
После изменения настроек и исправления запросов результат стал следующий:
| Показатель | Ноябрь 2016 | Декабрь 2016 | Январь 2017 | Февраль 2017 |
|---|---|---|---|---|
| Однопоточное восстановление («холодный»/«прогретый») (мин.) | 293/265 | 215/196 | 172/162 | 219/203 |
| Од
Вступайте в нашу телеграмм-группу Инфостарт "Фоновые задания" потоки "менеджер потоков" "менеджер фоновых заданий" распараллелить "восстановление партий" многопоточность См. такжеИнструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта 1С:Предприятие 8 Платные (руб) Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С. 16500 руб. 02.09.2020 273732 1523 422 Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Программист Руководитель проекта 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Россия Платные (руб) Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP, УНФ, КА и т.д.). Поддерживаются серверные и файловые базы, управляемые и обычные формы, интерфейс 8.5. Может выполнять свертку одновременно в несколько потоков, а также без непосредственного участия пользователя. Решение в Реестре отечественного ПО. 24900 руб. 20.08.2024 77250 389 171
20.08.2024
331
389
171
77250
Пакетная печать Печатные формы Инструментарий разработчика Программист 1С:Предприятие 8 Платные (руб) Расширение для создания и редактирования печатных форм в системе 1С:Предприятие 8.3. Благодаря конструктору можно значительно снизить затраты времени на разработку печатных форм, повысить качество и прозрачность разработки, а также навести порядок в многообразии корпоративных печатных форм. Обновление версии от 21.04.26 22570 руб. 06.10.2023 41356 121 54 Инструментарий разработчика Нейросети Платные (руб) Первые попытки разработки на 1С с использованием больших языковых моделей (LLM) могут разочаровать. LLMки сильно галлюцинируют, потому что не знают устройства конфигураций 1С, не знают нюансов синтаксиса. Но если дать им подсказки с помощью MCP, то результат получается кардинально лучше. Далее в публикации: MCP для поиска по метаданным 1С, справке синтакс-помощника и проверки синтаксиса. 15250 руб. 25.08.2025 67343 136 38 Инструменты администратора БД Инструментарий разработчика Роли и права Программист 1С:Предприятие 8 1C:Бухгалтерия Россия Платные (руб) Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах. 17000 руб. 10.11.2023 27161 99 46 SALE! % Инструментарий разработчика Инструменты администратора БД Системный администратор Программист Бизнес-аналитик 1С:Предприятие 8 1С 8.3 1С 8.5 1C:ERP 1С:УТ 1С:ДО 1С:Бухгалтерия 3.0 1С:ERP. Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 11 Россия Платные (руб) Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом. 14.01.2013 215118 1246 0 Инструментарий разработчика Программист 1С:Предприятие 8 Платные (руб) Инструмент для написания и отладки кода в режиме «1С:Предприятие». Представляет собой консоль кода с возможностью пошаговой отладки, просмотра значений переменных любых типов, использования процедур и функций, просмотра стека вызовов, вычисления произвольных выражений на встроенном языке в контексте точки останова, синтаксического контроля и остановки по ошибке. В консоли используется удобный редактор кода с подсветкой, контекстной подсказкой, возможностью вызова конструкторов запроса и форматной строки. 1.3.11 Доработан механизм контекстной подсказки по метаданным 9500 руб. 17.05.2024 55513 189 63 Информационная безопасность Инструменты администратора БД Инструментарий разработчика Учет документов Системный администратор Программист Бизнес-аналитик Бухгалтер Пользователь Руководитель проекта 1С 8.3 1С 8.5 Розничная и сетевая торговля (FMCG) Платные (руб) Контроль ввода данных в 1С: проверка заполнения реквизитов, обязательные поля, контроль перед записью и проведением, запрет проведения документа. Позволяет настраивать любые проверки данных в 1С 8.3/8.5 от обязательных полей до сложных условий – без открытия конфигуратора и написания кода. Готовое расширение, которое подключается и работает сразу. 6000 руб. 15.04.2026 3157 5 0 Отзывы
Остальные комментарии
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
7.
KazanKokos
11
29.05.17 11:33
Сейчас в теме
(6) имеется ввиду в самой публикации вместо картинок крестики
(13) Результаты из первой таблицы?
Колонки с месяцами - это месяцы за который восстанавливались партии. Есть 2а показателя: "Однопоточное восстановление" и "Параллельное восстановление" Первый показывает сколько времени занимало восстановление партий в типовом варианте (один поток): для восстановления партий за "Ноября 2016" при первом запуске было затрачено 293 мин. При повторном (сразу после первого) запуске - 265 мин. При этом при использовании механизма распараллеливания тот же самый период "Ноябрь 2016" при первом запуске завершился за 30 мин, а при повторном за 24 мин. Точно так же по остальным месяцам Да, забыл дать пояснение, Это время при распараллеливании на 10 потоков
(16) тут есть одно уточнение... По графикам ниже видно, что распараллеливание не напрямую на 10 потоков идет, а в зависимости от количеств "свободных" документов (если они в графе не зависят от других документов). Более того в обработке отключена процедура "СдвигПоследовательностиВперед" и "пропускаются" приходные документы. За счет этого и достигается ускорение близкое к х10. Если бы база была с 2 поступления на 2 склада по 1-номенклатуре и 10000 документов списания (с этих складов), то тут уже не получилось бы распараллелить больше чем на х2 :).
Вижу восстановление партий . Но в бух нет партий , а есть последовательности - с измерением Организация и СостояниеПроведения.
Ничего больше нет. Аналогично в регистре бухгалтерии только Организация. валюта, подразделение - так что и модифицировать последовательность не удасться. Бухи и так отдельно по организациям перепроводят. Правильно ли понимаю - что в данном случае (типовые Бух и все что на них) - Ваша обработка никак не поможет ?
(18) На БУ не тестировал, затачивал под УПП. Но суть одна и та же. Типовые метаданные не меняются, добавляется новый общий модуль. Последовательность в УПП тоже только в разрезе "Организаций". Типовой код изменен не значительно, примерно как в "Общей схеме". Также в цикле перебираются документы подаются в "менеджер потоков" - он уже строит по документам зависимость на основании Ресурсов (см. раздел "Расчет ресурсов") - рассчитанных ВАМИ (см. раздел "Обработать события разработчика") и посылает их по потоки. Мое "Восстановление партий" можно рассматривать, как еще один вариант примеров, но у кого-то результат и на нем заработает :). Для БУ - не помню архитектуру, но по прикидкам основное распараллеливание будет по субконто 10/41/43 счетов.
(19)
вариант примеров, но у кого-то результат и на нем заработает :). Для БУ - не помню архитектуру, но по прикидкам основное распараллеливание будет по субконто 10 счета Не понял. В бухии идут проводки зависящие от других проводок сделанных ранее по организации, с разными счетами и субконто. Не только ресурсы - но счета и субконто. Например - зачет авансов по документу если стоит - будут сформированы проводки по зачету авансов. Не представляю как все это можно распараллелить (в рамках одной организации)
(21) тут не надо путать теплое и мягкое. Последовательность партий восстанавливается своей обработкой, а последовательность взаиморасчетов своей - ни та ни другая документы не перепроводит. Они двигают свои регистры / счета. Вот в рамках этих обработок и происходит "вклинивание" и описание правил по распараллеливанию.
(24) Без проблем:
Создаете общий модуль "МенеджерПотоков" - туда переноситься весь код из модуля объекта - предоставляемой обработки. Затем по рекомендации, создаете еще один общий модуль Имя без разницы (укажите его при Инициализации) с экспортной функцией "ОбработатьСобытиеРазработчика" В этой функции на примере картинки из ( «ОбработатьСобытиеРазработчика()») описываете свой код. По обработке документа, расчету ресурсов, получению ответ ну в принципе и все
(75) РЛ, листы были в первой статье, во второй я их решил не выкладывать, т.к. они имеют все же определенную специфику, а не общее решение. Прикладываю обработку по РЛ, но под версию 2.0 ее придется чуток подправить "напильником"
Прикрепленные файлы:
! РЛ - Параллельно.epf
(21) Попробую на пальцах объяснить на взаиморасчетах. Есть:
Док1 (Поступление) - Контрагент1, Договор1 5000 Док2 (Поступление) - Контрагент1, Договор2 4000 Док3 (Поступление) - Контрагент2, Договор3 3000 Док4 (Взаимозачет) - Контрагент1, Договор1 / Контрагент2, Договор3 5000 - перенос долго Док5 (Платежка) Контрагент2, Договор3 Док6 (Платежка) Контрагент1, Договор2 что примерно приведет к тому что на рисунке. На каждой итерации будет проведено столько документов сколько показано, на первой 3, на второй 2, на третьей 1. В итоге 6 документов проведено за 3 шага, вместо 6 при стандартном подходе Но для ресурсов Вы должны написать свой алгоритм в событии "ПриПолученииМассиваРесурсов". (Пример взят из головы) Прикрепленные файлы:
(25) в строительстве больше разрезов при проведении документов - объект строительства, договор, заказ, склад, организация, номенклатура, документ-партия для материалов - все это "измерения" в терминах 1С для учета.
1) пробовали ли вы использовать для перепроведения последовательности документов стандартный механизм восстановления последовательности по измерениям? 2) главный фокус статьи - это разделение всех документов по разрезам учета (см. первый абзац) - добавив в учет дополнительные таблицы для хранения этой информации? когда я столкнулся с проблемой перепроведения документов для пересчета определенного показателя, я реализовал и описал в статье подобный подход
(57)
в строительстве больше разрезов при проведении документов - разрезов больше, но тех что не вызывают блокировок значительно меньше. Например в БУ, можете сколь угодно много добавлять разрезов, но "мельче" чем "Склад"+"Номенклатура" раздробить (распараллелить) не получиться.
(57) пробовали ли вы использовать для перепроведения последовательности по измерениям?
Вы меня сейчас озадачили... Какой стандартный механизм позволяет восстанавливать последовательность по измерениям. Единственное измерение стандартного механизма - это "Организация", ну еще "УУ" и "БУ". Все, больше мне ни какие измерения для восстановления в стандартном механизме не доступны (мне не известны). (57) главный фокус статьи - это разделение всех документов по разрезам учета Если под разрезами вы понимаете "УУ" и "БУ", в принципе можно и так сказать, но в данной статье я его не использовал, каждый документ восстанавливался одновременно по двум учетам. Распараллеливание идет на уровне данных документа. Грубо, если у вас есть два склада не связанных между собой (и производства в том числе), то восстановление можно запустить в 2 потока.
(57) добавив в учет дополнительные таблицы для хранения этой информации? - нет в БД ни какие новые объекты метаданных создавать не надо. Все рассчитывается и формируется "на лету" согласно заложенных Вами алгоритмов.
(57) описал в статье подобный подход с Вашей статьей я знаком
(58)
Вы меня сейчас озадачили... Какой стандартный механизм позволяет восстанавливать последовательность по измерениям. Единственное измерение стандартного механизма - это "Организация", ну еще "УУ" и "БУ". Все, больше мне ни какие измерения для восстановления в стандартном механизме не доступны (мне не известны).
дополнительные измерения можно запрограммировать, чтобы ускорить общее перепроведение - вот статьи об этом: суть такая - Измерения. Последовательности могут иметь подчиненные объекты, называемые измерениями, которые создаются на закладке Данные окна редактирования. Если для последовательности не создано ни одного измерения, то при восстановлении данной последовательности будут перепроводиться все входящие документы. Если требуется, чтобы данная последовательность учитывала не все, а вполне определенные ситуации, то в последовательность включают измерение. В этом случае перепроводить нужно будет только те документы, которые изменяют состояние регистра с учетом свойств измерения. Если изменяется состояние регистров, участвующих в последовательности, то неактуальными становятся более поздние документы с теми же значениями в реквизитах (перечислены в свойстве измерения Соответствие реквизитам документов), которые содержатся в реквизитах удаленных (добавленных) записей регистров (перечислены в свойстве измерения Соответствие реквизитам движений). Например, последовательность учитывает изменение состояния регистров по документам Приходная накладная и Расходная накладная. Если требуется учитывать дополнительные критерии необходимости перепроведения указанных документов (например, нужно перепроводить документы по определенному значению номенклатуры), то в последовательность следует добавить измерение. В палитре свойств измерения указать его тип (СправочникСсылка.Номенклатура) и установить связь с реквизитами регистров.
(60) Что такое "измерение" объекта "последовательность" я знаю. И сколько переделок в коде вслед за этим необходимо сделать - тоже представляю. Я думал Вы говорите о типовой обработке восстановления последовательности и о возможности запустить восстановления по "скрытым" для меня измерениям.
(58)
- разрезов больше, но тех что не вызывают блокировок значительно меньше. Например в БУ, можете сколь угодно много добавлять разрезов, но "мельче" чем "Склад"+"Номенклатура" раздробить (распараллелить) не получиться.
про это - не понял вас в целом, по вашей статье - у меня создалось поверхностное мнение, что вы распараллелили перепроведение по измерениям - да, это помогает ускорить стандартный механизм типового восстановления последовательности при закрытии месяца. такая идея уже заложена в механизм объекта конфигурации "Последовательность документов". Вы наверное сделали как-то по другому.
(61) Вы не совсем поняли мой механизм. Все что вы добавляете в объекты метаданных - это только 1 (один) общий модуль. В целом этого достаточно, но я рекомендую, для своих обработчиков создавать по дополнитльному общему модулю.
Ни каких изменений других объектов производить не требуется. У Вас вообще в БД может не быть объекта последовательность, а объекты мы можете обрабатывать в разных потоках. Рассматриваемый пример "восстановление последовательности" - это как один из множества вариантов использоватния механизма. Вы же используя его можете восстановить последовательность расчетов с контрагентами, или рассчитать зарплаты или вообще произвести произвольную обработку данных в потоках, хоть заполнить таблицу значений расчетными суммами или записать перезаписать массу объектов. Но для этих целей больше подойдет . В нем данный механизм получил расширенные функции
(58)
Грубо, если у вас есть два склада не связанных между собой (и производства в том числе), то восстановление можно запустить в 2 потока.
- нет в БД ни какие новые объекты метаданных создавать не надо. Все рассчитывается и формируется "на лету" согласно заложенных Вами алгоритмов.
ясно. можно и "на лету" - значит задействуете ОЗУ - ресурсы памяти - такое же хранение данных только в других таблицах, и на обработку собственных запросов требуется такое же время и ресурсы ОЗУ... в итоге у вас насколько сложные (длинные) запросы получились? Я не убеждаю ни в чем, просто технические детали реализации вашего механизма уже интересны ...
(62) Опять же советую Вам ознакомиться со статьей не поверхностно, а детально, если она Вас заинтересовала, т.к. сейчас Вы не до конца осознаете что и как реализовано. Не поверите, но я вообще при реализации рассмотренного примера, не изменил ни одного типового запроса. А если в цифрах, то общий модуль менеджера потоков ~1000 строк кода, это то что не требует корректировок, а объем кода обрабатывающий события менеджера это примерно еще 500 строк и ВСЕ. Этого достаточно чтобы партии "типовой" (уже не совсем, т.к. чуток вмещаться надо для инициализации менеджера потоков, но и это можно вынести во внешнюю обработку) УПП отрабатывали в разы быстрее, чем типовой обработкой. Я сомневаюсь, что в 500 строчках кода можно наваять что-то
(62) в итоге у вас насколько сложные (длинные) запросы получились?
Да там есть запросы для получения "ресурсов", но я не скажу, что выборка из регистра с отбором по ссылке документа это сложный запрос, или определение присутствие и заполненность поля "Заказа" в передаваемом на обработку документе - это что-то сверх сложно и непостижимое :)). В дальнейшем я предлагаю дискуссию перенести в чат обновления , т.к. там все последние доработки механизма. (62) просто технические детали реализации вашего механизма уже интересны
Предлагаю скачать работающий механизм () и ознакомиться с работой рассмотренных примеров, там уже не восстановление партий. Думаю многие вопросы так же отпадут. А так, конечно задавайте вопросы с удовольствием отвечу, только просьба все же ознакомиться с 2мя статьями, что бы не пришлось повторять то что написано выше :)
(66) ясно, интересный подход ))
код вашего модуля открыт? (66) или определение присутствие и заполненность поля "Заказа" в передаваемом на обработку документе
надо знать конфу, которую обрабатываешь, поскольку Заказ может сидеть в реквизите "Сделка" , "ДокументОснование" или просто "Заказ" или использовать структуру подчиненности и по типу объекта проверять все реквизиты....
(70)
код вашего модуля открыт?
(70) надо знать конфу
Само собой! Менеджер - универсален, а пакет обработчиков событий - индивидуален :) В принципе разработчики могут менеджером пользоваться как платформой для разработки. Если конечно есть желание, то могут свое написать - основные идеи я изложил. Но как показывает практика - это долго, не с точки зрения разработки (я версию написал примерно за 2 недели, да и то я четко представлял что необходимо сделать), а с точки зрения тесотов :)
(57)
в строительстве больше разрезов при проведении документов
Не обратил внимание к чему вы писали сообщение. На самом деле, для выстраивания зависимости объектов, разрезов может быть произвольное количество не обязательно 2. Можно реально использовать все что вы перечислили, а можно все, но не разом, а в совокупности, например, построить две и более зависимостей: 1ая по "Объект строительства" + "Организация" + "Заказ"; 2ая по "Организация" + "Склад" + "Номенклатура" + "Документ-Партия" и 3я по "Объект строительства" + "Договор". Все это приведет к формированию 3х графов, которые в итоге сольются в 1 смешанный граф и далее обрабатываются по описанной выше схеме, текущий документ не будет передан в обработку, пока не будут обработаны ВСЕ ведущие документы с такими же наборами данных (ресурсов). Надеюсь понятно описал. Опять же прошу ознакомиться с примерами особенно с
(18) Еще дополню... При расчете "Ресурсов" вы определяете как будет выстраиваться зависимость документов. Можно сделать только по "Складу", тогда все документы у которых один и тот же склад будут выстраиваться в очередь. Можно по склад + номенклатура, тогда документы с одним складом могут проводиться параллельно если у них разный состав номенклатуры. Тут все уже будет зависеть от Вас и потребностей заказчика. Можно например реализовать (бред, но можно), не только по субконто 10/41/43 счетов, а по произвольному другому алгоритму зависимости, например, по году рождения ответственного за документ - если у ответственных за документ один и тот же год рождения, то эти документы проводятся друг за другом, а другие параллельно, но тут уже могут возникнуть блокировки и/или взаимоблокировки накладываемые архитектурными реализациями платформы. Так что распараллеливать надо то - что можно распараллелить.
31.
KazanKokos
11
31.05.17 17:17
Сейчас в теме
(30) еще 10000руб предстоит заплатить чтобы все увидеть :)
(30) Завтра, напишу ещё демообработки "по универсальнее" с функцией перезаписи N-элементов произвольного справочника. Предоставив пользователю возможность выбрать справочник, количество потоков и количество перезаписываемых элементов
(36) А если нет?
Действительно с этой разработкой не знаком, и не смогу сейчас привести примеры отличий. Если Вы с ней знакомы или есть знающий знакомый, можем пообщаться в чате и составить карту отличий (если Вы в этом заинтересованы). Бегло я попытался поглядеть, что в цф-ке. Но готовых тестовых примеров не нашел, так что сложно оценить "что", "как" и "где" должен писать разработчик работающий с предоставленным Вами модулем. Могу кратко описать, что может мой модуль: * Модуль состоит только из одного общего модуля без регистров и перечислений (подглядел в цф-ке) * Автоматическое построение зависимости объектов для обработки (что позволяет реализовать восстановление партий, о чем говориться в статье); * отдельно выделенный, от модуля менеджера потоков, модуль(и) разработчика со своими алгоритмами (модуль менеджера может быть без изменений вообще); * возможность описать код разработчика вне метаданных (в самой внешней обработке), что позволяет их (внешние обработки) писать без изменения конфигурации БД; * возможность одновременного запуска нескольких менеджеров с разными алгоритмами (В разработке сейчас обсуждается расчет зарплаты, где есть ряд выполняемых операций, при этом есть четкая зависимость одних операций от других, но ряд операций при этом могут выполняться параллельно в одной из веток дерева(графа), а следом идущие операции (этой же ветки), только при завершении всех этих параллельных. При этом каждая операция будет стартовать свой менеджер потоков, который будет распараллеливать выполнение конкретно взятой операции, но это пока в обсуждении, но пока все укладывается в возможности модуля); * перезапуск ФЗ, в случае вылета; * ну и еще что-то по мелочи, все возможности описаны в статье :) Что увидел в описании "TaskManagerFor1C" это ограничение по количеству выполнений одной операции, после чего она считается не выполненной. Такой функционал в моем модуле на сегодня отсутствует, но потребность в нем тоже есть и это уже заложено в следующих обновлениях, как и ряд других идей :) Если есть конкретные вопросы задавайте
(37) Приведенное решение не мое.
Спасибо за краткое описание, собственно и хотелось по-быстрому, не вникая глубоко, понять отличия. Теперь вижу, что стоит изучить подробнее. В разработке сейчас обсуждается расчет зарплаты
Если не сложно, ткните ссылкой в обсуждение. Правильно ли я понимаю, что планируются готовые модули разработчика для типовых конфигураций, в частности, для ЗУП?
(38)
Если не сложно, ткните ссылкой в обсуждение. Обсуждение внутренне, в рамках нашей организации, не для общего использования :) (38) Правильно ли я понимаю, что планируются готовые модули разработчика для типовых конфигураций, в частности, для ЗУП?
Не совсем :) Я выкладываю только модуль позволяющий производить распараллеливание. А разработчик/разработчики разрабатывают вторую часть которая опирается на модуль. По аналоги с 1С. Я предоставляю платформу (мой модуль), а разработчики пишут свое отраслевое решение (модули с обработчиками событий под конкретные задачи). Так что вопрос о разработке модулей для типовых конфигураций я отдаю на волю разработчикам :) Разработчик (фриланс / франч) берет модуль для разработки (с закрытым кодом) добавляет свой модуль с обработкой событий и выставляет конечному клиенту(ам). Под каждую разработку отдельное приобретение, но на неограниченное количество поставок клиентам. Или Конечный пользователь приобретает модуль (с открытым кодом) и использует его как хочет на неограниченное количество проектов в рамках своей организации .
(38)
Теперь вижу, что стоит изучить подробнее.
В ближайшее время выложу дополнительные картинки с разъяснением расчета ресурсов, при каких условиях как строится граф, а то пишут, что это достаточно сложная часть и демо примера - мало :)
(37)
Если есть конкретные вопросы задавайте
вопросов пока нет, просто тема интересная, разрыхлил новые статьи на ИТС Ускорение процесса восстановления последовательности взаиморасчетов в БП КОРП да и вообще, что представлено на гитхабе - это опять-таки плагин на базе имеющихся фоновых заданий - и кто-то может сделает для конкретной задачи оптимальнее зная специфику учета.
(63)
это опять-таки плагин на базе имеющихся фоновых заданий Так на данном ресурсе - много можно отнести к категории "плагин". Вопрос в том, что для реализации множества задач можно использовать 1 общий подход - это ведь значительно эффективнее чем каждый раз писать одно и то же или чуть чуть другое с нуля.
Что разработка на гитхабе, что моя разработка предлагают Вам такой инструмент, используя который Вы можете ускорить выполнение своих обработок в РАЗЫ!!! и для этого может потребоваться не так много сил и времени. В частности рассмотренного тут примера, разве плохо иметь возможность восстанавливать последовательность партий месяца в рабочее время за 20-30 мин, когда работают 200+ пользователей без "блокировок" транзакций???? Если нет, тогда чем плохи данные плагины? А типовой механизм такого не позволит даже если использовать предложенный Вами способ добавления измерений в объект "Последовательность".
(63)
Ускорение процесса восстановления последовательности взаиморасчетов в БП КОРП
Ознакомился с предоставленной статьей. Решение верное, но предложенная реализация имеет ряд ограничений: 1. Необходимость находить документы "корректировка долга" и "авансовый отчет" для определения границы обрабатываемого периода. 2. Множество запусков и остановок фоновых заданий (после обработки документов ФЗ перезапускается с новыми данными). 3. Не ясно как обрабатываются ошибки, если в переданном пакете документов один из них не провелся. 4. Нет возможности запускать в рабочее время, т.к. может быть ожидание захвата таблицы и после 20 сек, ФЗ просто прекратит свое существование :) можно еще найти "ограничений" предложенного механизма если знать что там точно реализовали и как. Я конечно не говорю, что предложенный мной механизм не имеет ограничений, но данные "подводные камни" в нем отработаны
44.
Йожкин Кот
1009
28.07.17 13:35
Сейчас в теме
Если бы вложили готовый модуль для встраивания в БП3 - цены бы Вам не было! Но и без этого - несомненный плюс!
(44) Готовый модуль чего? Восстановления партий? т.к. именно его тут нет :). Честно подумывал над этим, но я проводил оптимизацию под УПП 1.3, и под условия нашей организации. А в других организациях могут быть свои условия, потребности и доработки. Кроме того в моих алгоритмах использованы не все возможности распараллеливания, например, у нас нет характеристик, и их я не встраивал в алгоритмы событий, а у кого то они могут быть в данном случае мой алгоритм будет снижать возможность распараллелить проведение и так далее.
Хотя если будет заинтересованность, наверное выложу, как пример :)
(44) Более того... Разработку таких модулей (обработчиков событий) я предлагаю сообществу.
PS Да, да, знаю, что защита примитивна. Но хоть что-то :) Если вы планируете делать разработку с поддержкой многопоточности на основе данного модуля и предлагать ее потенциальным покупателям, то уповаю на Ваше благоразумее в плане приобретения полной версии. Если Вы являетесь конечным покупателем, то для Вас одно приобретение для одной организации, на неограниченное количество проектов. Если фриланс/франчайзи :), то одно приобретение на один проект (обработку), но на неограниченое количество конечных пользователей.
47.
o.nikolaev
217
03.08.17 12:12
Сейчас в теме
Статья отличная, но орфографические ошибки просто убивают всякое желание продолжать чтение. Исправьте! Есть же Word в конце-концов!
(47) Большое спасибо за замечания. Основная часть стать была написана в Word (я бы не осилил написать столько, с таким «незначительным» количеством ошибок :)). БОльшая часть ошибок была допущена в результате правки и обновления разделов, их увы делал на «коленке».
Что нашел - поправил, надеюсь стало лучше.
а можно отдельную статью только кратко и с простыми примерами?)в раза 6 кратче )
оч тяжело читать и сразу все механизмы описывать наверно нет смысла, для меня лично, но труд как сказали эпохальный , выглядит слишком зло.
(49)
Если кратко, то что оставить? Если написать в 6 раз меньше, то надо выкинуть 5/6 статьи. Для «простоты», что требуется от разработчика - скачайте демообработки, а именно «Запись справочников», а в нем Вас будет интересовать – модуль формы и модуль объекта, а именно Функция «ОбработатьСобытиеРазработчика». Под условием: "Если РазрезМенеджеров = "Запись справочника - Независимая запись" Тогда" Это САМЫЙ простой способ распараллелить :) Под условием: ИначеЕсли РазрезМенеджеров = "Запись справочника - Зависимость по четности кода" Тогда Это САМЫЙ простой способ распараллелить при выстраивании зависимости объектов :) Получилось в 6 раз короче??? В данном случае придется самому пытаться понять, как оно устроено - зато кратко. Будут вопросы - обращайтесь к данной статье. Основные сложности и прочие события реализованы для получения ответов от потоков на клиент. А так же предоставляют возможность собирать информацию для отчетов в момент работы.
(50)
Как запустить ,примеры что можно запустить, например обмен какой-то или отчёт.. это тоже что и у вас или нет? Я вот не помню видел вроде как можно запустить отчет в отдельном потоке и свернув его например делать дальше работу.
(51) Самый простой способ опробовать:
* Скачиваем "Универсальный «Менеджер потоков Демо»"; * Скачиваем демообработки; * Устанавливаем "Менеджер потоков" на любую конфигурацию * Запускаем демо обработки, где от разных настроек обработок будут разные результаты. (Формирование расчетных листов оттестировано только на УПП 1.3, возможно будет работать в ЗУП, но под рукой не было - не проверил). Это самый простой способ распараллелить, и не самый оптимальный. Его основные минусы: * Необходимо обдумывать как разбить обрабатываемый массив на части (порции) (В предоставленной статье порция - это склад). * ФоновыеЗадания.ОжидатьЗавершения(МассивЗаданий); тут узкое место в том, что пока ПАЧКА фоновых заданий не отработает полностью новое не запуститься. Если в первую выборку попадет один гигантский склад и 9 маленьких, но при этом в общей выборке их предположи 11, то последний 11 склад будет ждать завершения всего блока, ходя 9 потоков по сути будут давно свободны.
* Не реализована обратная связь между потоками и клиентом, хотя допил не большой, * И САМОЕ ГЛАВНОЕ, если в потоке произойдет ЛЮБАЯ ошибка, хоть ожидание захвата таблицы, он просто прекратит свою жизнь, и Вам ни как об этом не сообщит В текущем "менеджере потоков" это все учтено. :) Максимально близкое решение предоставили на (36), но отличия, бегло обнаруженные, я так же описал в (37)
55.
abadonna83
45
10.10.17 13:10
Сейчас в теме
Интересно что переписали в Процедура ЗаполнитьЗапросПартийНаСкладахУпр и тд.
Добрый день! Спасибо за большой труд.
Можно ли решить с помощью менеджера такую задачу: При интерактивном проведении документов пользователями, отправлять документы в менеджер потоков, где они проводятся. После проведения получать информации о статусе (проведен или нет). Как можно выполнить обработку документов в потоке при запуске с разных рабочих мест?
(78) Добрый день!
А зачем Вам при "интерактивном проведении" выполнять это в потоках? Если у Вас грамотно настроена блокировка данных, документы и так буду проводиться параллельно, ведь проводить их будут разные пользователи. "Менеджер потоков" позволяет выбрав объекты для обработки (не обязательно документы) в одном сеансе (одним запросом), обработать их несколько потоков, а не стандартным перебором с обработкой.
(80) это называется допроведение документов. В данном случае это имеет смысл. Сначала вы складываете документы в очередь (Регистр сведений), затем запускаете обработку, которая считывает накопленную очередь и отправляет документы в менеджер потоков, где они уже будут обработаны в потоках. Так - да сделать можно. Про ответ, об успешном проведении, можно не заморачиваться, а просто в потоке удалять документ из очереди (регистра сведений).
Но опять есть один вопрос. А в очереди, между вызовами, будут сотни документов? Просто смысл делать многопоточное проведение, если с этим в состоянии справить и одна последовательная очередь. Вот если документов успевает нападать столько что в 1 поток их провести не получается (очередь копиться быстрее чем происходит проведение), вот тогда имеет смысл думать о менеджере потоков.
87.
user869483
22.10.21 15:49
Сейчас в теме
как понять какое фоновое задание основной программы вызвало менеджер потоков?
Автор:
(DarkAn)
Рейтинг: 1108 Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора. Публикация:
№ 626117 Создание 26.05.17 16:59 Обновление 25.09.17 15:32 Статистика:
Просмотры 61790 Загрузки 14
Рейтинг
207 Комментарии 87 Характеристики:
Код открыт Да Рубрики Универсальные функции HighLoad оптимизация Инструментарий разработчика Кому Программист Тип файла Архив с данными Платформа 1С:Предприятие 8 Конфигурация 1C:Бухгалтерия Операционная система Не имеет значения Страна Россия Отрасль Не имеет значения Налоги Не имеет значения Вид учета Не имеет значения Доступ к файлу Абонемент ($m) |
