10000 строк в заказе?

[R.Safianov]

Цитата:

Сообщение от IKA

Тут наш волшебный архитектор хочет загонять в систему через EDI заказы от клиентов по 10 000 строк в каждом. (т.е. это не разовый импорт заказов)

Я немного ошеломлена столь смелым, мягко выражаясь, подходом, но мне не хватает доказательной базы.

Есть ли какие-нибудь документы (на english). которые анализируют перформанс подобных решений и требования к серверу?

PS: У меня нету доступа к partnerSource, но если там есть что-то дельное по теме приведите плз линк.

AX2012 R2

Ну заказы пол беды. Но если будут инвойсироваться в таких объемах, то не "взлетит паровоз".
В 2012 R2 разноска накладных страдает старыми болячками:
1) При объемах больше 1000 тормозить начинает расчет налогов (вроде как правило расчета итогов меняли).
2) После "доработки" первого пункта на 3000 начинает тормозить корреспонденция.
При этом на тестовой машине (4-е ядра, 30 ГБ оперативной) утилизация процессора падает до 40%, оперативная память съедается вся. Идет своп данных на диски и нагружает их очень сильно. АОС падает где-то через 4 часа без завершения задачи.
3) Параллельная разноска больших заказов приводит к взаимным блокировкам InventDim. После исправления первого пункта пробовал разносить заказы с 3000 строк в 4 потока. Поэтому пришлось еще с этим немного повозится. По результату оптимальное соотношение было достигнуто на уровне 8-ми потоков на один пакетный АОС.

При этом разноска складских журналов идет на больших объемах (пробовал разносить 18000 - 26000 строк в одном журнале).

[Logger]

Цитата:

Сообщение от R.Safianov

1) При объемах больше 1000 тормозить начинает расчет налогов (вроде как правило расчета итогов меняли).
2) После "доработки" первого пункта на 3000 начинает тормозить корреспонденция.

А как вы лечили 1-й пункт ?
Вот этого
Оптимизация класса Tax
достаточно ?
(для 2012-й - соотв. код сидит в PurchInvoiceJournalPost.writeTaxAmount_W() / SalesInvoiceJournalPost.writeTaxAmount_W() )

Цитата:

Сообщение от R.Safianov

3) Параллельная разноска больших заказов приводит к взаимным блокировкам InventDim.

Именно InventDim ? Вы не опечатались ? Странно, откуда на InventDim блокировки. новые аналитики не должны бы создаваться.

[R.Safianov]

Цитата:

Сообщение от Logger

А как вы лечили 1-й пункт ?
Вот этого
Оптимизация класса Tax
достаточно ?
(для 2012-й - соотв. код сидит в PurchInvoiceJournalPost.writeTaxAmount_W() / SalesInvoiceJournalPost.writeTaxAmount_W() )




Именно InventDim ? Вы не опечатались ? Странно, откуда на InventDim блокировки. новые аналитики не должны бы создаваться.

По первому пункту коллега trud может подсказать достаточно или нет (его рук дело).

По второму пункту точно на InventDim. В многопоточном режиме периодически простреливает сообщение: "Невозможно создать запись в Складские аналитики (InventDim). Номер аналитики.... Запись уже существует".
Тут наверное даже не блокировки, а особенность выделения номеров в потоках. В какой-то момент InventDim созданный одним потоком не виден в другом потоке и создается повторно.