AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 06.04.2021, 17:36   #21  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
В нашем случае (в пике 50К сообщений по 2Кб) затраты на брокера (Apache ActiveMQ 5) вообще не ощущаются на общем фоне.Все время уходит на формирование сообщений и их обработку при приемке.

Причем если отправку еще можно ускорить, например запустив несколько потоков, то приемку нет. Единственные средства улучшения для приемки - пакетные сообщения и замена железа.
При этом пакетные сообщения усложняют отправку и не ускоряют ее никак (в одном потоке)
угу.

Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
Возвращаясь к вопросу.
100500 сообщений по 1Мб (например) это почти 100Гб сырых данных. За какое время их передавать надо и как далеко?.
а почему по 1Мб?
я вроде написал "коллекция - список/массив/мап/контейнер/таблица"
В мире аксапты элементы коллекций это максимум размер страницы MS SQL = 8Кб
Очень-очень редко мемо поля до 4Гб. Но про это я бы обязательно сказал.

все-таки для мира аксапты хорошие допущения:
= размер элемента до 8кб
= размер буфера рабочего окна 64Кб (максимальный размер XML в WCF по умолчанию)
= размер коллекции более 100500 элементов

Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
Если проблема в размере сообщений, можно попробовать их сжать при отправке.
нет, с размером элементов как раз никаких проблем.
вопрос про количество элементов, которое гарантировано не помещается в одно сообщение.


Цитата:
Сообщение от AlexMoskvichev Посмотреть сообщение
Или вообще,
Write CSV -> 7zip -> SFTP -> 7zip ->Read CSV
Или более современно, в parquet
Может оказаться вполне быстро и автоматизировать не сложно.
Через WCF можно управляющие команды подать, с метаданными файла
файла? какого файла? каким магическим образом вдруг файл передался?
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 18:13.
Старый 06.04.2021, 17:44   #22  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Vadik Посмотреть сообщение
Нет, не считаю, действия действительно разные. Я считаю что это не царское (издателя) дело пихать (передавать) данные во всех подписчиков число которых в общем случае может превышать единицу. Иногда может быть оправдано, но в общем предпочел бы чтобы этим сам подписчик или брокер занимался.
А ты в этом смысле понимаешь слово передать.
Нет, я не имел в виду транспортный уровень.

Да, надо было использовать глагол "отправить"
вопрос звучал бы "как правильно отправить".

Я имел в виду, что Аксапта (как endpoint) инициирует процесс подготовки и отправки данных в другую Аксапту (другой endpoint). В WCF это означает Аксапта должна заполнить коллекцию с элементами и вызвать какой-нибудь осмысленный метод для этой коллекции.

для какого-нибудь другого брокера это будет нечто похожее.
Аксапта готовит данные в специальном формате и вызывает что-нибудь осмысленное для этих данных.

И WCF, и другие брокеры, насколько я знаю, все имеют ограничение на размер сообщения. Размер сообщения меньше, чем размер всех элементов.

вопрос - как правильно готовить, чтобы отправить (передать) свои данные другому endpoint.

современный правильный ответ - использовать потоки.
но в Аксапте нет потоков.

какой способ отправить много элементов коллекции является правильным для Аксапты?
__________________
полезное на axForum, github, vk, coub.
Старый 06.04.2021, 17:56   #23  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
прирожденный продавец
Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.
Цитата:
Сообщение от mazzy Посмотреть сообщение
и как правильно делают упомянутые тобой решения?
упомянутые мною решения, как платные так и open source, делают одно - он реплицируют данные из системы А в систему В. В режиме, близком в режиму реального времени, хотя временной лаг все равно есть. Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву. И, некоторые, установки агента, что уже не по нраву и безопасникам.
  • Если задача стоит "надо сделать так, чтобы в системе В мгновенно отображались данные системы А" - горячее копирование, личный кабинет, репликация баз данных и т.п. - то это только CDC.
  • Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.
  • Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.

Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.

С Уважением,
Георгий
За это сообщение автора поблагодарили: mazzy (2).
Старый 06.04.2021, 18:12   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Не только. Более того, продажами софта я не занимаюсь. Я за всеобщую цифровую грамотность.
я тоже!

- пойдем простым логическим путём
- пойдем вместе!
https://www.youtube.com/watch?v=wK1fq2QZbRk

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Да, и это требует включения режима расширенного логирования, так как они читают логи, что BDA не всегда по нраву.
во-первых, я уже говорил, что прямой доступ к запросам и/или к структуре таблиц - это плохо с точки зрения изолированности систем

во-вторых, я не зря упомянул ax2009 и ax2012
в ax2012 (в той самой, где перехерачили главную книгу) перехерачили очень много других таблиц. в результате ОЧЕНЬ много таблиц в ax2012 не совпадают с ax2009

взять тривиальную таблицу единиц измерения.
в единицах измерения разное все - количество таблиц, количество полей, ограничения на поля. даже одинаковые по смыслу enum'ы разные!

Нажмите на изображение для увеличения
Название: ax2009.PNG
Просмотров: 34
Размер:	48.3 Кб
ID:	13155 Нажмите на изображение для увеличения
Название: ax2012.PNG
Просмотров: 36
Размер:	70.6 Кб
ID:	13156

Да, я понял что ты хотел сказать про синхронизацию баз данных.
я не считаю этот способ правильным ни для Аксапт, ни для других разнородных клиентов.

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Какое именно решение считать "правильным" зависит от задачи и от критичности скорости изменений. Да, еще есть критерий гарантированной доставки сообщений и двухсторонней репликации / разруливания конфликтов репликации, но это за рамками обсуждения, иначе еще про шины данных придется рассказывать, такие как IBM WebSphere.
начинается...
да, я тоже за грамотность.

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

я думаю, что для аксапты не актуально горячее копирование.
я думаю, что для аксапты актуальны эти варианты:
Цитата:
Сообщение от George Nordic Посмотреть сообщение
  • Если изменений не так много и скорость репликации не так важна, но тоже критична, то можно обойтись брокером сообщений.
  • Если изменения необходимо синхронизировать раз в день или раз в неделю, то можно реплицировать таблицы bulk load или просто инкрементом передавать новые / измененые / удаленные данные.
Причём, ни фига НЕ "инкрементом"!
инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 18:19.
Старый 06.04.2021, 18:42   #25  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
во-первых, я уже говорил, что прямой доступ к запросам и/или к структуре таблиц - это плохо с точки зрения изолированности систем
Это не совсем так, есть класс задач, когда по-другому - никак. Например, отображение проводки в личном кабинете. Это или CDC, или триггер на таблице. И там и там есть нюансы. Пример 2 - данные из транзакционных систем в MPP DB для решения оптимизационных задач - next best offer, подбор такси, "рекомендуем посмотреть", контекстная реклама и т.д.
Цитата:
Сообщение от mazzy Посмотреть сообщение
Да, я понял что ты хотел сказать про синхронизацию баз данных. я не считаю этот способ правильным ни для Аксапт, ни для других разнородных клиентов.
Для DAX - да, согласен и даже рассказал почему. Про "других разнородных клиентов" - я бы на был настолько категоричен, честно.
Цитата:
Сообщение от mazzy Посмотреть сообщение
инкремент за dDOS'ит системы нафиг. Для аксапты характерны таблицы, в которых поля обновляются часто. Какая-нибудь последняя себестоимость в карточках номенклатуры, например.
а насколько нужно ее часто реплицировать? Это и брокера убьет нафик. Плюс возможны будут варианты, когда изменение со старой себестоимостью придет позже сообщения с новой себестоимостью - не факт что брокер будет успевать доставить все по очереди(!) или приёмник - обрабатывать по очереди отправки. Значит, еще и версионность вводить и проверять. Оно точно надо?

С Уважением,
Георгий
Старый 06.04.2021, 18:49   #26  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
а насколько нужно ее часто реплицировать? Это и брокера убьет нафик. Плюс возможны будут варианты, когда изменение со старой себестоимостью придет позже сообщения с новой себестоимостью - не факт что брокер будет успевать доставить все по очереди(!). Значит, еще и версионность вводить и проверять. Оно точно надо?
воооот! прекрасные вопросы.
а какие есть варианты решений?

как технарь со знанием, можешь выделить важные параметры и граничные значения и как они влияют?

повторю, вопрос, в котором я постарался зафиксировать действительно важные на мой взгляд параметры:

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

готов послушать для вариантов, где используется не WCF. но все остальные слова остаются в вопросе.

готов принять вводные характерные для аксапты. например, это точно не "горячее копирование". например, нормальная скорость 1 изменение в секунду. например, размер элемента в коллекции до 8кб, а число элементов измеряется скорее сотнями тысяч, но никак не сотнями миллионов. и другие характерные для аксапты вводные.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 06.04.2021 в 18:55.
Старый 06.04.2021, 18:53   #27  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
1К изменений в секунду.
Это кто-то погорячился. Я такие скорости только в большом телекоме видел. Поправь, плиз.

С Уважением,
Георгий
Старый 06.04.2021, 18:56   #28  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Это кто-то погорячился. Я такие скорости только в большом телекоме видел. Поправь, плиз.

С Уважением,
Георгий
легко. пусть будет 1 изменение в секунду.
если кому-то хочется другую границу - вводите в свое обсуждение и вперед.

хотя, конечно, 1000 проводок в секунду для аксапты легко.
ну, пусть будет 1 (одна).
не принципиально для данного обсуждения, на мой взгляд.
__________________
полезное на axForum, github, vk, coub.
Старый 07.04.2021, 10:22   #29  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.

Давай уточню сначала по CDC: из БД 2009 в БД 2012 скорость репликации будет очень высокой, если RecID будет выделяться самой БД. Но если Rec будет выделять AOS, то он станет бутылочным горлышком, а если еще и номерные серии надо заполнять...

То же самое и с брокерами. В принципе, за счет распараллеливания и оптимизации размера пакетов - то хоть 1К в секунду, хоть миллион. Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.

Абстрагируясь от DAX, то если мы говорим про надежную доставку, то это - запись на диск. Таким образом надо смотреть на пропускную способность сети и скорость записи на диск. Например, для AWS это 40 000 IOPS составляет при пакете в 16 КБ и 20 000 IOPS при 32 КБ

Таким образом, я не вижу проблемы в передаче 100500 сообщений. Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля. Если доверить эту задачу БД, а служебные поля заполнять автоматом по некому шаблону механизмами БД, то данная проблема снимается. Но вряд ли этим снимается проблема последовательной обработки сообщений.

С Уважением,
Георгий
Старый 07.04.2021, 10:34   #30  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Bingo!
__________________
-ТСЯ или -ТЬСЯ ?
Старый 07.04.2021, 10:42   #31  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Давай немного переформулирую. В основном затык происходит не на стороне брокера или CDC, а на стадии обработки принятого сообщения.
...
Я вижу проблему в их парсинге, если будет задействованы механизмы DAX - тот же АОS, которые будут заполнять служебные поля.
даже не столько в парсинге, сколько в валидации входащих данных.

т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне.

все понимаю про принимающую сторону.
поэтому в вопросе сформулировано о передать/отправить.

принимающая сторона в части парсинга и валидации входящих данных - отдельный вопрос.

но хотелось бы все-таки получить ответ на свой вопрос - как правильно передавать/отправлять много элементов коллекции в Аксапте, где нет встроенных стримов.

Цитата:
Сообщение от George Nordic Посмотреть сообщение
Но с какой скоростью будет его разбирать пакетный сервер если мы говорим по DAX? И параллельно запускать обработку вряд ли получится, так как есть вероятность что сообщение с новой себестоимостью в данном случае будет обработано до сообщения со старой себестоимостью.
Я уже сказал, пусть будет 1 запись в секунду. Пусть будет 10 записей в секунду.
По-моему, не принципиально для заданного вопроса.
__________________
полезное на axForum, github, vk, coub.
Старый 07.04.2021, 10:58   #32  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от mazzy Посмотреть сообщение
т.е. ты тоже как и Vadik передать/отправить сводишь к "запросить" и к принимающей стороне.
Потому что задачу надо решать комплексно. Смысл в посылке 100500 сообщений, если они не будут обработаны и будут тупо писаться в буфер на диске?

Извини, но твой вопрос
Цитата:
Сообщение от mazzy Посмотреть сообщение
как правильно передавать/отправлять много элементов коллекции в Аксапте, где нет встроенных стримов.
Выглядит как "как вкорячить 1000-лошадный двигатель на шаху?". Мы с Вадимом пытаемся объяснять про тормозную систему и управляемость, в ответ слышим "да ладно тормоза, главное разогнаться!". Результат как бы немного предсказуем.

С Уважением,
Георгий
Старый 07.04.2021, 11:18   #33  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
можно я еще раз повторю свое первое предложение в первом сообщении этой ветки?
Цитата:
Сообщение от mazzy Посмотреть сообщение
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Потому что задачу надо решать комплексно. Смысл в посылке 100500 сообщений, если они не будут обработаны и будут тупо писаться в буфер на диске?
ты это мне говоришь?

===============================
итак,

всё ещё надеюсь услышать мнения по вопросу:

ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?

дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены

что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения.

лично я не вижу, как брокер/транспорт может принципиально повлиять на принимающую сторону. парсинг и валидация на принимающей стороне будут плюс-минус одинаковыми. поэтому сознательно вывел за рамки данного обсуждения вопросы парсинга и валидации на принимающей стороне. и вообще, вывел за рамки обсуждения принимающую сторону. но если вы знаете способ передачи, который существенно повлияет на принимающую сторону, то можно обсудить и её. вводите свои вводные в свое сообщение и вперед. с удовольствием послушаю.

Добавлено:
огромное спасибо всем участникам обсуждения, что заставили задуматься и сформлировать ограничения и вводные. В результате получается вопрос, который становится похож на правильно сформулированный.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 07.04.2021 в 11:36.
За это сообщение автора поблагодарили: sukhanchik (4).
Старый 21.04.2021, 02:01   #34  
CDR is offline
CDR
MCTS
MCBMSS
 
236 / 175 (6) ++++++
Регистрация: 27.11.2003
Цитата:
Сообщение от mazzy Посмотреть сообщение
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
__________________
Dynamics AX Experience
Старый 21.04.2021, 14:28   #35  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от mazzy Посмотреть сообщение
всё ещё надеюсь услышать мнения по вопросу:
ax2012,ax2009: как правильно передать 100500 элементов коллекции через WCF?
По-моему, вся тема - про то, что ax2012,ax2009: правильно передать 100500 элементов коллекции НЕ через WCF
Цитата:
Сообщение от mazzy Посмотреть сообщение
дополнительные вводные, которые были уточнены по ходу ветки и в личной переписке:
* "передать" в смысле "отправить"
* в аксапте есть recId и нумераторы
* в аксапте нет встроенной поддержки потоков (stream).
* аксапта 2009 работает на .net 3.5
* аксапта 2012 работает на .net 4.0 (не 4.5)
* размер элемента коллекции в Аксапте до 8Кб
* размер коллекции до 100500 элементов, но вряд ли больше 2^32
Мне лично думается, что как только возникает 100500 элементов для передачи, интеграция должна становиться асинхронной, а связь ax2012 и ax2009 через WCF как-то не очень ложится на идею асинхронного обмена (без собственных dll, "и чтобы эти собственные dll'ки работали в адресном пространстве аксапты"). Это вроде само собой разумеется уже: если требуется обрабатывать в системе много документов, то надо писать пакетную обработку с распараллеливанием. Если требуется передавать между системами большие объемы данных, то надо делать асинхронный обмен.
На тему проектирования интеграций есть хорошая статья у Дениса Трунина, где он предлагает для начала определиться с такими моментами:
  • Топология решения интеграции
  • Требования для потока данных
  • Анализ свойств потока данных
  • Определение качества обслуживания (QoS)
  • Производительность
  • Доступность и надежность
  • Безопасность
  • Масштабируемость
  • Логирование и м... "неподдельность" (nonrepudiation)
И уже по совокупности требований будет ясно, WCF это окажется или не WCF...
Цитата:
Сообщение от mazzy Посмотреть сообщение
* вместо WCF можно обсуждать любой другой брокер/транспорт
* предполагаем, что middlware отсутствует. но мы можем сделать любой
* для простоты предполагаем, что все компоненты под нашим контролем и вопросы безопасности решены

что беспокоит в первую очередь - накладные расходы на передачу каждого сообщения.
А что 100500 элементов будут парситься/валидироваться/обрабатываться в один поток слишком медленно - не беспокоит? А как при распараллеливании приемки данных не забить все доступные потоки на пакетном сервере/серверах (привет от закрытия склада), тоже не беспокоит?
Цитата:
Сообщение от mazzy Посмотреть сообщение
лично я не вижу, как брокер/транспорт может принципиально повлиять на принимающую сторону. парсинг и валидация на принимающей стороне будут плюс-минус одинаковыми.
Брокер/транспорт при асинхронном обмене даст принимающей стороне возможность обрабатывать сообщения тогда и в таком темпе, в каком ей комфортно, не просаживая другие поддерживаемые бизнес-процессы. А стороне-отправителю даст возможность не ждать ответа и не отправлять все 100500 элементов, скажем, одним куском повторно, если у принимающей стороны что-то не заладилось.
В обсуждении много говорилось про очереди, шины данных и т.п. По-моему, если нужно перебрасывать между двумя системами такие объемы данных, стоит посмотреть в сторону какого-нить RabbitMQ хотя бы. Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах, но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на размер буфера под значимые типы (тот же string), которое по умолчанию, кажется, равно 1Мб - см. Падает клиент при прикреплении файла. Так что если утоптать 100500 элементов в один большой XML/JSON, то на принимающей стороне с ним может быть непросто работать. Я бы в связи с этим постарался разбивать передаваемые данные на блоки меньше 1Мб каждый.
Цитата:
Сообщение от CDR Посмотреть сообщение
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
Кажется, у Макконнелла в Code Complete было:
Цитата:
Для построения метровой башни требуется твердая рука, ровная поверхность и 10 пивных банок, для башни же в 100 раз более высокой недостаточно иметь в 100 раз больше пивных банок. Такой проект требует совершенно иного планирования и конструирования.
Старый 21.04.2021, 14:58   #36  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
...тоже не беспокоит?
конечно же беспокоит.
поэтому и была создана тема.

что ж, критика навиного подхода к передаче данных между разными системами - зачетная.
именно поэтому и создана тема "как правильно"

каковы твои предложения?
для начала какую именно технологию ты называешь асинхронным обменом?
Цитата:
Сообщение от gl00mie Посмотреть сообщение
...при асинхронном обмене
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 21.04.2021 в 15:27.
Старый 21.04.2021, 15:03   #37  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Разбивать ли коллекцию из 100500 элементов на блоки при передаче? Решать, конечно, на местах
собственно тема КАК правильно решить на местах?

Цитата:
Сообщение от gl00mie Посмотреть сообщение
но я бы тут вспомнил про то, что в ядре, начиная с AX2009, есть ограничение на
а с чего ты решил, что об этом кто-то забыл?

Цитата:
Сообщение от gl00mie Посмотреть сообщение
и не отправлять все 100500 элементов, скажем, одним куском повторно
а кто-то говорил "одним куском"?!
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 21.04.2021 в 15:11.
Старый 21.04.2021, 15:07   #38  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от CDR Посмотреть сообщение
Я так полагаю, вопрос "ax2012,ax2009: как правильно передать 1 элемент через WCF?" уже успешно решен?
когда ж вы ТЗ научитесь читать?

Цитата:
Сообщение от mazzy Посмотреть сообщение
Сразу скажу, что решение есть, конечно.
Хотелось бы обсудить вопрос как лучше и как правильно
__________________
полезное на axForum, github, vk, coub.
Старый 21.04.2021, 15:49   #39  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от mazzy Посмотреть сообщение
Сразу скажу, что решение есть, конечно.
Ну так и на чем в итоге остановились?
Старый 21.04.2021, 16:02   #40  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Ну так и на чем в итоге остановились?
пока разбиваем на чанки с фиксированным числом элементов.
и написан код для обслуживания этих чанков.

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

но "остановились" - это неправильное слово.
скорее, приняли в качестве первой версии.
__________________
полезное на axForum, github, vk, coub.

Последний раз редактировалось mazzy; 21.04.2021 в 16:06.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Denis Trunin's Blogs: Examples of AX2012/ AX2009 performance problems Blog bot DAX Blogs 0 12.01.2020 05:02
Перенос и адаптация кода с Ax2009 на Ax2012 R3 matew DAX: Прочие вопросы 10 23.01.2015 19:52
как передать значение из диалога в форму, вызываемую через menuItem? алька DAX: Программирование 9 25.06.2007 16:46
Передать контейнер в job через COM sao DAX: Программирование 5 21.02.2006 19:34
Как в параметрах подпрограммы передать массив элементов. Yuri Safronov DAX: Программирование 3 14.10.2002 16:35
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:47.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.