05.10.2020, 12:08 | #1 |
Участник
|
ProgressBar на сервере Акс2012
Вопрос возник у меня из комментария mazzy в соседней теме:
DAX09: некорректное отображение полоски ProgressBar Цитата:
Сообщение от mazzy
с сервером проблема долгой "отрисовки" стоит гораздо острее.
в серверном прогресс-баре счетчик записывается в таблицу, которая является общей для всех процессов. и обновление SysProgress параллельными процессами в легкую может стать бутылочным горлышком на сервере. выше я говорил, что некоторые на проектах запрещают использовать ProgressBar вообще. конечно же не для того, чтобы усложить жизнь пользователей а именно из-за того, что натыкаются на это бутылочное горлышко. в основном проблема возникает, когда программист отлаживает RunBaseBatch на клиенте с прогрессбаром, а потом этот же класс безо всяких модификаций начинает выполняться в пакетнике. есть разные подходы для решения проблемы с прогресс-баром на сервере. что-то сделано и в Аксапте - обратите внимание, как забавно работает процент выполненных работ в пакетных заданиях 1. Типичное мое использование прогресса в RunBaseBatch это где-то в run начать this.progressInit("Обработка", 1, #AviUpdate)... Проваливаемся и видим, что в этом случае по умолчанию в в серверный SysOperationProgressServer передается _bypass=true. А это значит никакая логика по отображению прогресса не отрабатывает. В SysProgress ничего не пишется и ничего не читается. Мое задание на сервере вообще никак дополнительно не нагружает его своим прогрессом. 2. Хорошо. Предположим я продвинулся и сделал свой, progress = RunbaseProgres::newServerProgress(...). Тогда все обновления прогресса в итоге вызывают update(false) в SysOperationProgressServer. Где написано: X++: ... if (currentTickCount - ticksAtLastUpdate < #ProgressUpdateInterval) return; ... Это значит, одно задание апдейтит SysProgress максимум 1 раз в 0,5сек. Правда это делается в отдельном conn = new UserConnection(), что наверное накладывает доп расходы по времени и ресурсам. У нас в Конфигурации сервера параметр "Максимальное число потоков в пакетном задании" = 8. (не знаю откуда взялось это число, но по-моему оно дефолтное. У кого-то значительно больше?). Т.е. в пике 8 обновлений в 0,5 сек. В итоге получаем вопрос. 8 обновлений в 0,5 сек - это действительно может стать бутылочным горлышком? С учетом, что у таблицы SysProgress оптимистическая конкурентная модель и все 8 процессов обновляют разные записи. Ну если не 8, то сколько станет проблемой, если сложить все задания со всех пакетные серверов? |
|