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