Отмена закрытия склада

[Logger]

Привет всем.
Хочу обсудить отмену закрытия склада (версия ax 2009 RU5, но думаю, что актуально и для 2012 - 7.0)

Отмена закрытия склада в пакете имеет неприятную особенность - при отмене генерируется очень много дополнительных пакетных задач (InventCostClosingCancel_WorkInvent) по одной на каждую отменяемую номенклатуру.
В нашем случае получается от 10 до 35 тысяч пакетных заданий. Естественно они занимают все доступные потоки на пакетном сервере и все остальные пакеты вынуждены ждать пока пройдет отмена, что нарушает график работы других пакетов. Также из-за того что пакетный сервер запускает пакетные задания не мгновенно (а где то раз в 30-60 секунд просматривает перечень пакетов) - то получается, что неэффективно время используется - много времени может тратиться вхолостую.

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

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

Любой из этих вариантов будет работать быстрее, чем стандартный. Не будет забивать доступные потоки в пакетном сервере, соответственно, не будет мешать другим пакетам. Вариант Б пожалуй даже получше будет - более эффективно задействует мощность сервера, так как в любой момент времени будут задействованы все запланированные задания помощники.


Вопрос такой :
1. Есть ли у описанных подходов недостатки по сравнению со стандартом?
2. Почему в стандарте так не сделали? Ведь варианты а)-б) сами напрашивались по аналогии с закрытием склада.

Может я чего-то не понимаю в логике работы отмены закрытия склада ?

[gl00mie]

Есть вариант не переписывать отмену закрытия, оставить все почти как есть, но паковать отдельные пакетные задачи InventCostClosingCancel_WorkInvent в "пакеты", которые бы обрабатывались последовательно в рамках одного потока на пакетном сервере.
Где-то была публикация на тему того, как команда разработчиков, отвечающая за финансовый блок, перед выпуском AX 2009 задалась целью разнести 100 тысяч журналов ГК за приемлемое время. В ходе тестирования обнаружилось, что создавать отдельную пакетную задачу на разноску каждого журнала слишком неэффективно: на таком количестве задач пакетная инфраструктура начинает сама отжирать слишком много ресурсов, плюс многочисленные простои между запусками отдельных задач снижают общую производительность. В итоге придумали механизм "пакетирования":

• выбирается критерий для определения размера "пакета" (для разноски журналов это может быть суммарное количество строк, для отмены закрытия склада - количество номенклатур);
• при создании заданий обработки данных они нарезаются на "пакеты" примерно равного размера;
• очередная пакетная задача создается на "пакет" в целом, а не на каждое отдельное задание обработки в нем, при этом для выполнения "пакета" используется небольшой класс-обертка;
• при запуске с помощью пакетной инфраструктуры класс-обертка последовательно запускает задания обработки из своего "пакета".

Это позволяет, с одной стороны, снизить нагрузку на пакетную инфраструктуру, с другой, сократить время простоя между запусками отдельных заданий обработки, а с третьей, при желании - управлять количеством потоков пакетного сервера, которые будут задействованы, за счет изменения размера "пакетов". В приложении это все представлено классами BatchTaskBundle, BatchTaskBundleAssembler и их наследниками.

PS. На счет того, почему отмена закрытия реализована не так эффективно, как само закрытие склада: вероятно, руки не дошли, либо сценарий отмены был не самым приоритетным. В конце концов, на пресейлах можно козырять скоростью закрытия склада, но как-то странно выпячивать скорость отмены закрытия

[Logger]

Спасибо за отзыв.
В принципе, я примерно это и имел в виду под вариантом А (наверно описал криво).
Т.е. если раньше InventCostClosingCancel_WorkInvent обрабатывал только одну номенклатуру, то теперь сделать чтобы мог перечень позиций обрабатывать, а набор позиций как раз при постановке пакетного задания определять в соответствие с желаемым количеством параллельно работающих помощников (InventCostClosingCancel_WorkInvent).

В общем, мысль пошла в том же направлении.

[gl00mie]

Вот и меня настигла задача оптимизации отмены пересчетов себестоимости. Правда, в моем случае, основная нагрузка оказалась вызвана не столько количеством номенклатур, сколько количеством производственных заказов (есть много спецификаций - BOM-ов - и много связанного производства). В одном из кейсов отмена пересчета себестоимости для ~300 номенклатур в рабочем окружении привела к генерации мега-пакетного задания на 124+ тысячи пакетных задач, бОльшая часть из которых была связана с пакетными заданиями InventCostClosingCancel_WorkProd. Под тяжестью такой нагрузки производительность пакетной инфраструктуры коллапсировала, и 30+ пакетных серверов смогли запускать вместо обычных нескольких сотен лишь ~15 пакетных задач одновременно. В моем случае решил проблему с помощью этого инструмента, пакуя все генерируемые пакетные задания в ограниченное число потоков. Это не так идеально, как InventCostList + top picking, но всё лучше, чем коллапс пакетной инфры и вот это всё из-за отмены одного пересчета себестоимости.