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

[EVGL]

Еще кредитный лимит с учетом открытых строк имеет убийственный эффект на "длинных" заказах.

[trud]

из собственного опыта - на числах близких к 1000 строк начинает нелинейно тормозить расчет налогов, но это поддается оптимизации
на числах за 3000 строк уже почему то уходит в небеса расчет корреспонденции
CIL на время разноски влияет слабо, что странно конечно. скорость разноски пару строк в секунду
ну то есть если не использовать налоги и корреспонденцию то наверное и 10 000 можно обрабатывать

[macklakov]

Если правильно помню, важно не количество строк в заказе, а количество строк в разносимом документе. Т.е. если заказ на 10 тыс. строк будет разноситься как 100 накладных по 100 строк, то проблем возникать не должно.

[Link]

Цитата:

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

Если правильно помню, важно не количество строк в заказе, а количество строк в разносимом документе. Т.е. если заказ на 10 тыс. строк будет разноситься как 100 накладных по 100 строк, то проблем возникать не должно.

Именно, в моем предыдущем сообщении, как раз одна строка разносится как 10 тыс. Если не использовать номенклатуру с серийными номерами, тогда как одна строка разносится мгновенно. А к примеру продажа одной строки 10 тыс. симкарт превращается в разноску 10 тыс. строк, потому что они должны иметь уникальный серийник.

[Vadik]

Цитата:

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

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

Как пользователя, меня бы напрягали сообщения "у вас что-то недорезервировано или недоотобрано в строке 9867, поправьте и попробуйте еще раз" после пары часов разноски.
Таких заказов много в системе создается \ разносится одновременно ? С точки зрения масштабирования "решения" я бы предложил все же бить заказ на мелкие и разносить пакетной обработкой, иначе у Вас тут и там алгоритмических "мин замедленного действия" (см. выше) разложено чуток а исполнение - на одном процессорном ядре AOS-а, скорее всего виртуальном. Мы в принципе гоняем 800-900 строчные документы через AIF (вроде тьфу-тьфу справляется), но с другой стороны по-другому и не можем - это каталог, его по частям другая сторона не примет, не подавится ли на 10000 - интересно конечно но я бы постарался таких трюков избегать по возможности

[Ivanhoe]

Подыму-ка тему
Кто-то пробовал разносить тысячи строк в накладных продаж / закупок в 2012?

[Vadik]

Цитата:

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

Кто-то пробовал разносить тысячи строк в накладных продаж / закупок в 2012?

Накладную по заказу на закупку размером более 2000 строк (в "российской" компании стандартным функционалом) разнести практически нереально. ИЧСХ - основные косяки на уровне локализации

[R.Safianov]

Цитата:

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

Подыму-ка тему
Кто-то пробовал разносить тысячи строк в накладных продаж / закупок в 2012?

Пробовал на R2 разносить 1000, 1500, 2000, 2500, 3000, 3600 (уникальные SKU).
Заказы разносился в рамках Retail (разноска стейтментов).
До 1300 полет +- нормальный (бенчмарк тест от МС как раз дальше этой границы не пытается уйти).
Дальше все печально... После исправления недочетов по расчету налогов разноска заказа на 2000-3000 строк занимает 40-50 минут.
Время +- линейно увеличено по объему. Т.е. если разносить заказ кусочками по 100 строк, то суммарное время будет потрачено такое же.

[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 созданный одним потоком не виден в другом потоке и создается повторно.

[Ivanhoe]

Спасибо за статистику. А такой крамольный вопрос - после разноски накладной, ТОРГ-12 и СФ реально сформировать?

По журналам ГК / складу подтверждаю. В CIL в целом разносится хорошо, и по 50 000 - 100 000 строк журналы разносил, в разы быстрее чем в той же 2009.

[R.Safianov]

Цитата:

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

Спасибо за статистику. А такой крамольный вопрос - после разноски накладной, ТОРГ-12 и СФ реально сформировать?

По журналам ГК / складу подтверждаю. В CIL в целом разносится хорошо, и по 50 000 - 100 000 строк журналы разносил, в разы быстрее чем в той же 2009.

Ну, это же розница. ТОРГ-12 точно никто не печатал.
СФ - формировались и включались в книгу продаж.
Печать документов не смотрел. Для тех задач не было нужды.

[Ivanhoe]

Меня именно печать волнует.

И кстати, про розницу. Никто не копал разноску? Субъективно заказ из стейтмента разносится намного быстрее, чем аналогичная накладная по обычному заказу. Нет ли там какой-то оптимизации именно для розницы?

[R.Safianov]

Цитата:

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

Меня именно печать волнует.

И кстати, про розницу. Никто не копал разноску? Субъективно заказ из стейтмента разносится намного быстрее, чем аналогичная накладная по обычному заказу. Нет ли там какой-то оптимизации именно для розницы?

Разница есть в создании заказа и махинациях с транзакциями. Дальше по-моему все идет через стандартный сервис разноски.

Оптимизация есть в агрегации строк. Но это к созданию заказа.

[oip]

Цитата:

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

По журналам ГК / складу подтверждаю. В CIL в целом разносится хорошо, и по 50 000 - 100 000 строк журналы разносил, в разы быстрее чем в той же 2009.

Иван, скажи, пожалуйста, каков был порядок времени разноски журнала ГК из 100к строк и на каком железе?

[Ivanhoe]

Пока только по памяти:
100К журнал ГК - примерно 1,5 часа. Но тут сильно зависит от сложности фин. аналитик.
40К журнал склада - примерно 40 минут.

В последние сколько-то лет стоимость железа стала намного ниже лицензий и услуг. Скажем так, от 16 ядер и 48Г на SQL, от 4 ядер и 8Г на один сервис АОСа. Указанные цифры примерно на таком же железе.