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

[IKA]

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

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

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

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

AX2012 R2

[ice]

что вас смущает?

[Wamr]

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

[Logger]

В 2009-й, например это
Оптимизация класса Tax
Плюс квадратичные зависимости во времени разноски от числа строк в ГК.

Есть подозрения что в 2012-й все осталось по прежнему.
Лучший способ - взять в один заказ перелить строки из кучи реальных заказов. и попробовать разнести.
Один тест даст ответы на все вопросы.

[Logger]

Цитата:

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

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

Мы выкручивались такими способами :
1. Группировали по номенклатуре. Гораздо прозе отгрузить одну строку с номенклатурой 1 чем 10 строк с одной и той же номенклатурой
2. Делали кучу накладных по 100 строк. Для 3 тысяч строк быстрее быол сделать 30 накладных по 100 строк чем одну на 3 тысячи.

[Logger]

Кстати, если соберетесь делать тест, хорошо было бы если бы поделились результатом.
По опыту, в 2009-й нелинейные эффекты становились заметны начиная с 400-500 строк в заказе. А если поставить 1000 и более то очень заметно.

[ice]

не тестировал заказы на продажу, но заказы на покупку при ~1000 строках: отборочная накладная ~8 часов, финансовая накладная ~2 часа
ПС разноска не в пакетном режиме без использования IL

[Logger]

ппц.
Это еще хуже чем у нас было до оптимизаций в 2009-й (порядка 30-45 минут для финансовой накладной). Конечно еще зависит от мощности железа, но тренд понятен.

Ваши цифры с включенной корреспонденцией счетов?
Накладные расходы были ?

[IKA]

1) Пробовать на девелоперском/тестовом - не показательно, а клиентские рабочие сервера у нас еще пока "в проекте" ( + данных надо много, чтобы показательный тест получился, а не полупустой базе гонять)

2) Подобные вещи желательно решать еще на стадии проектирования и ,обычно, по моему опыту заказы даже по 1000 строк - уже гарантированные проблемы с производительностью (до 2012). Кстати. не знала , что есть проблемы в алгоритмах тоже. Всегда был бест практис - подумать, как можно пересмотреть бизнес требования и обойтись хотя бы большим количеством заказов, но с меньшим количеством строк в каждом

Но тк это все эмперические знания, то я не могу ими аппелировать ,+ может, я не права, и в 2012 случилось чудо и все уже возможно

[IKA]

Цитата:

не тестировал заказы на продажу, но заказы на покупку при ~1000 строках: отборочная накладная ~8 часов, финансовая накладная ~2 часа
ПС разноска не в пакетном режиме без использования IL

IL как раз должна повышать производительность. Почему вы без IL разносите?

[Wamr]

если есть возможность, то можно провести тест на 100, 200, 300 и т.д. строк и смотреть как меняется время, если линейно, то можно спрогнозировать время на 10000, а если экспоненциально, то лучше сразу отказаться в пользу нарезки меньших заказов.

[Logger]

Цитата:

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

Но тк это все эмперические знания, то я не могу ими аппелировать ,+ может, я не права, и в 2012 случилось чудо и все уже возможно

Я думаю если вы потребуете построить пример с большим числом данных, замерив там время, то никто не вправе будет отказать.

По поводу тестовой среды - раз нет сопоставимой тестовой среды, то можно в рабочей Аксапте создать тестовую компанию и в ней создать заказ с большим числом строк (желательно максимально повторить условия из рабочей компании, те же номенклатуры, финансовые аналитики и.т.п.). Сломать вы ничего не сможете, так как для примера не надо модификаций. Заказа можно вручную создать или джобом.

Разнести этот заказ и замерять скорость. поскольку база и сервер рабочие это и будет максимально адекватный тест.
Для упрощения можно включить отрицательные остатки.

[Logger]

Цитата:

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

IL как раз должна повышать производительность. Почему вы без IL разносите?

Если в коде есть нелинейные зависимости, то переход на IL не спасет. Переход на IL увеличивает скорость в X раз. А график N^2 растет с увеличением N гораздо быстрее и быстро перекрывает выигрыш от перехода на IL, так что в ваших условиях с большой вероятностью попадется заказ на котором все встанет даже под IL.

[IKA]

Цитата:

Если в коде есть нелинейные зависимости, то переход на IL не спасет. Переход на IL увеличивает скорость в X раз. А график N^2 растет с увеличением N гораздо быстрее и быстро перекрывает выигрыш от перехода на IL, так что в ваших условиях с большой вероятностью попадется заказ на котором все встанет даже под IL.

Я , может, чего-то не понимаю, но это независимые вещи:
1) при равном количестве строк обработка в IL даст прирост в X раз.
2) при изменении количества строк время возрастает квадратично
То есть, пусть время возросло, но при использовании IL, мы его все равно сократим в X раз.

Почему бы этим преимуществом вообще не пользоваться? Это не имеет отношения к постановке задачи в топике, но мне в принципе интересно

[Ivanhoe]

Про 2012 сходу не скажу, но до нее однозначно поддерживаю всех ответивших.

[Wamr]

разговор пошел в теорию
время работы большинства алгоритмов сильно зависит от количества чтений из БД. И тут все равно делаются они IL или X++ это не скажется в разы на производительности, так как основное время будет потрачено на обращение и ответ БД... imho

[Logger]

Я не говорю что IL вам не поможет. Ускорит конечно. И надо этим пользоваться.
Но если алгоритм криво работает, то замедление из-за роста числа строк в заказе быстро перекроет ускорение от IL. Также бессмысленно повышать частоту ЦП и.т.п. Кривой алгоритм надо исправлять.

Например у вас в заказе 500 строк. Обрабатываются за 10 минут. Включили IL. Скорость возрасла в 3 раза. Стало обрабатываться за 3,3 минуты. Хорошо? Конечно.

Сделали число строк 1000 как в вашем примере. Время вросла в 2^2 раза т.е. в 4 раза. примерно 13 минут.

Если 5000 строк то в 10^2 раз т.е. в 100 раз.
При таком резком росте уже неважно ускорил у вас IL выполнение в 3,3 раза или нет. Это мелочи по сравнению с резким ростом времени из-за роста числа строчек в заказе.

Функция N^2 очень быстро растет в зависимости от N. Поэтому всегда есть предел числа строк в заказе, больше которого время катастрофически падает. И перевод на IL или усиление железа не спасают, они просто отодвигают этот предел немного вверх (несильно).

[Logger]

Цитата:

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

разговор пошел в теорию
время работы большинства алгоритмов сильно зависит от количества чтений из БД. И тут все равно делаются они IL или X++ это не скажется в разы на производительности, так как основное время будет потрачено на обращение и ответ БД... imho

Нет ! В том то и дело !

Вспомните пример с корреспонденцией счетов.
Еще раз повторю ссылку
Оптимизация класса Tax

Там торможение возникает не от числа запросов к БД.
Там весь расчет крутится в памяти. Мапы, рекордсортедлисты и все такое.
Но на 1000 строк в заказе у меня в памяти получился список из 8-9 тысяч элементов, который постоянно многократно перебирался в процессе корреспонденции и за счет этого все тормозило. Т.е. даже быстрый проц и память не вытянули. А если строк заказа будет 10 тысяч, то вообще кранты.

Т.е. степенная функция растет настолько быстро ( надо анализировать алгоритм подробнее, возможно там зависимости не N^2 а еще хуже - N^3 и.т.п. но точно не лучше чем N^2) что при росте числа строк начинает тормозить даже без запросов к БД. Чисто на операциях в памяти.

P.S.
Хотя для большинства случаев, действительно все определяется скоростью запросов в БД. Тут вы правы.
Но в обсуждаемой проблеме все намного хуже.

[Link]

У моего текущего клиента активно используются серийные номера (InventSerial) для определенных номенклатур. Часто они продают по 10к и больше в одном заказе. Для каждой единицы товара происходит выделение серийного номера, что в таблицах выглядит примерно так - была строка заказа на 10к и одна запись в InventTrans после получаем 10к строк в InventTrans и изменение статуса серийников как использованных в InventSerial. В целом производительность относительно неплохая. Так разноска такого заказа занимает минут 30, и минут 5 выделение серийников. Причем кастомизация использует стандартные классы, так что особо ничего оптимизировать не получается. Проблемы приходят когда начинается массовая разноска в конце каждого месяца когда идет параллельная разноска во всех компаниях в системе. В этом случае разноска может "подвисать" на десятки часов.

[mnt_dx]

А мне интересно, что это за заказы с таким количеством строк?