ProgressBar на сервере Акс2012

[Perc]

Вопрос возник у меня из комментария 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. Где написано:

...
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, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?

[mazzy]

во-первых, спасибо что открыли новую ветку про 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 на клиенте с прогрессбаром, а потом этот же класс безо всяких модификаций начинает выполняться в пакетнике.

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

[mazzy]

Возвращаясь к вопросу:

Цитата:

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

В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?

конечно может.
когда одновремено выполняется много (несколько сотен) пакетов на сервере.

поэтому и появился runbaseProgress, который в "каких-то мелочах" отличается от SysOperationProgress.

[mazzy]

Цитата:

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

С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи.
Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов?

И да, давайте сразу, раз уж хорошо сформулировали вопрос (за что большое спасибо)

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