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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.10.2020, 12:08   #1  
Perc is offline
Perc
Участник
 
154 / 31 (2) +++
Регистрация: 05.03.2005
ProgressBar на сервере Акс2012
Вопрос возник у меня из комментария mazzy в соседней теме:
DAX09: некорректное отображение полоски ProgressBar
Цитата:
Сообщение от mazzy Посмотреть сообщение
с сервером проблема долгой "отрисовки" стоит гораздо острее.
в серверном прогресс-баре счетчик записывается в таблицу, которая является общей для всех процессов. и обновление SysProgress параллельными процессами в легкую может стать бутылочным горлышком на сервере.

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

есть разные подходы для решения проблемы с прогресс-баром на сервере.
что-то сделано и в Аксапте - обратите внимание, как забавно работает процент выполненных работ в пакетных заданиях
Поскольку я как раз один из тех, кто ничего не делает со своими классами на основе RunBaseBatch, перед запуском их на пакетнике Акс2012. Поэтому прочитав коммент, решил посмотреть код - в чем собственно проблема..
1. Типичное мое использование прогресса в RunBaseBatch это где-то в run начать this.progressInit("Обработка", 1, #AviUpdate)... Проваливаемся и видим, что в этом случае по умолчанию в в серверный SysOperationProgressServer передается _bypass=true. А это значит никакая логика по отображению прогресса не отрабатывает. В SysProgress ничего не пишется и ничего не читается. Мое задание на сервере вообще никак дополнительно не нагружает его своим прогрессом.

2. Хорошо. Предположим я продвинулся и сделал свой, progress = RunbaseProgres::newServerProgress(...). Тогда все обновления прогресса в итоге вызывают update(false) в SysOperationProgressServer. Где написано:
X++:
...
if (currentTickCount - ticksAtLastUpdate < #ProgressUpdateInterval)
    return;
...
и #define.ProgressUpdateInterval(500)
Это значит, одно задание апдейтит SysProgress максимум 1 раз в 0,5сек. Правда это делается в отдельном conn = new UserConnection(), что наверное накладывает доп расходы по времени и ресурсам. У нас в Конфигурации сервера параметр "Максимальное число потоков в пакетном задании" = 8. (не знаю откуда взялось это число, но по-моему оно дефолтное. У кого-то значительно больше?). Т.е. в пике 8 обновлений в 0,5 сек.

В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?
Старый 05.10.2020, 17:55   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,141 / 4030 (193) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
во-первых, спасибо что открыли новую ветку про ax2012

надеюсь это было осознано, поскольку ТА ветка была про DAX09.


Цитата:
Сообщение от Perc Посмотреть сообщение
Поскольку я как раз один из тех, кто ничего не делает со своими классами на основе RunBaseBatch, перед запуском их на пакетнике Акс2012. Поэтому прочитав коммент, решил посмотреть код - в чем собственно проблема..
1. Типичное мое использование прогресса в RunBaseBatch это где-то в run начать this.progressInit("Обработка", 1, #AviUpdate)... Проваливаемся и видим, что в этом случае по умолчанию в в серверный SysOperationProgressServer передается _bypass=true. А это значит никакая логика по отображению прогресса не отрабатывает. В SysProgress ничего не пишется и ничего не читается. Мое задание на сервере вообще никак дополнительно не нагружает его своим прогрессом.
...
В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?
Прекрасно!
Вы замечательно описали то, к чему пришли разработчики Аксапты с прогрессом на сервере.
В 2012 это действительно так.
Посмотрите в прошлых версиях

Цитирую себя дословно:

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

есть разные подходы для решения проблемы с прогресс-баром на сервере.
что-то сделано и в Аксапте - обратите внимание, как забавно работает процент выполненных работ в пакетных заданиях
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 05.10.2020, 17:58   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,141 / 4030 (193) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Возвращаясь к вопросу:
Цитата:
Сообщение от Perc Посмотреть сообщение
В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?
конечно может.
когда одновремено выполняется много (несколько сотен) пакетов на сервере.

поэтому и появился runbaseProgress, который в "каких-то мелочах" отличается от SysOperationProgress.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
Старый 05.10.2020, 18:16   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,141 / 4030 (193) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Perc Посмотреть сообщение
С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?
И да, давайте сразу, раз уж хорошо сформулировали вопрос (за что большое спасибо)

у всех SQL есть механизм эскалации блокировок,
когда с блокировки на уровне записей SQL превращаются в блокировки на уровне таблицы.
__________________
GitHub, Facebook, mazzy.priot, mazzy.music, coub.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
How to make your ProgressBar progress on server Blog bot DAX Blogs 0 27.12.2013 02:15
mazzy: Комфортный ProgressBar в DAX 2009 Blog bot DAX Blogs 5 04.09.2012 16:36
Отладка на сервере Bega DAX: Программирование 6 21.02.2011 15:38
mazzy: Комфортный ProgressBar Blog bot DAX Blogs 12 05.02.2009 19:54
Формат даты на сервере и клиенте bio_unit DAX: Администрирование 2 25.08.2004 16:44
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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