Progress bar

Как сделать Progress bar? Контроллер обрабатывает большое количество данных, отсылаю их по апи в 1с, хочу чтобы на странице отображался ход выполнения процесса - количество обработанных записей. Есть какие нибудь внятные примеры как это сделать?

0

Pantheonptz, не надо так делать. Никогда. Контроллер ни при каких условиях не должен загружаться долгими задачами. Его задача - или выполнить действие сразу или, если не может, поставить это действие в какую-то очередь, чтобы его выполнил уже другой сервис, который не будет ограничен во времени.

Рекомендую такой подход: контроллер принимает необходимые параметры от пользователя, формирует задачу, пишет её в базу и выдаёт пользователю какой-то ID этой задачи. Саму долгую задачу пускай решает уже отдельная служба в идеале работающая вне веб-приложения (реально отдельный процесс или в виде WIndows-службы или в виде консольного приложения постоянно запущенного) или, для простоты решения (но это не правильно!) в виде отдельного потока в самом веб-приложении.

JavaScript на клиенте будет периодически опрашивать веб-сервер (уже другой контроллер) на предмет статуса задачи с указанным ID и либо рисовать progress bar, если таковой статус дискретен, либо тупо отображать infinite progress, если статус "ещё не закончено".

Выполнять долгие задачи в веб-приложении не надо по двум причинам:
* вы занимаете поток из пула ASP.NET MVC, который мог бы обрабатывать другие запросы;
* IIS полностью контролирует жизнь веб-приложения и может со спокойной совестью его грохнуть (или перезапустить) в любой момент, ибо думает, что вы понимаете, что такие приложения про быстрый "запрос-ответ", а долгие задержки в контроллерах - явно зависания;

1

Сообщение от Usaga отдельная служба в идеале работающая вне веб-приложения

Чтож вы так не любите монолитные приложения... XD

0

Wolfdp, речь не о разделении ради разделения. Приложения хостящиеся в IIS себе не хозяева. IIS их может грохнуть потому, что потому. Оттуда и рекомендация не держать в веб-приложении никаких долгоиграющих сервисов. К .NET Core это не относится)

0

Если использовать для длительной задачи Hangfire? BackgroundJob.Enqueue запускает задачу в фоне. Допустим в фоне отправляются данные, страница при этом показывает прогресс сколько записей отправлено, после завершения предоставляется ссылка на скачивание лога, что добавлено и где с ошибкой.
Вот здесь есть про прогресс бар https://www.codeproject.com/Ar... ing-Live-D но как то непонятно.

0

Сообщение от Pantheonptz Если использовать для длительной задачи Hangfire? BackgroundJob.Enqueue запускает задачу в фоне. Допустим в фоне отправляются данные, страница при этом показывает прогресс сколько записей отправлено, после завершения предоставляется ссылка на скачивание лога, что добавлено и где с ошибкой.

Не забывайте, что эта страница отображается только пока вы её запустили. Обновили страницу и нужно снова отображать прогресс.
Это очень трудозатратные операции. После отображения страницы вы должны зацепиться в контекст выполняемой задачи. Как? нереал. Можно из выполняемой задачи обновлять БД, а ваш метод будет постоянно перечитывать данные для отображения, но... это нагрузка и блокировка базы.

Сообщение от Pantheonptz Вот здесь есть про прогресс бар https://www.codeproject.com/Ar... ing-Live-D но как то непонятно.

Это SignalR. Такая же хрень, только уже "из коробки".

Ваша проблема - откуда и как брать прогресс чтобы не положить остальное и отображать корректно и красиво. Вот тут и проблема, а не в том как прогресс выводить.

0

Ну можно в статической переменной хранить количество обработанных записей и ajax-ом получать из view ее значение. а статическую переменную будет изменять фоновый процесс. Также можно ввести флаг - static bool идет ли в данный момент процесс, чтобы после перезагрузки страницы ничего не путалось.

0

Сообщение от Pantheonptz Ну можно в статической переменной хранить количество обработанных записей и ajax-ом получать из view ее значение.

А теперь задумайтесь о таких вещах:
- больше одного пользователя. Значит переменная должно быть не одна, а много... dictonary? Причём привязка по какому-то признаку, например пользователь. А если этот таск должен выполняться больше 1 раза для одного пользователя? (например, массовые аплоады запущенные с разных страниц)
- упавший процесс не обновил значение переменной и ... она так и осталась true, 88%
Всё.. начинаются заглушки и костыли.

0

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

0

Pantheonptz, сессия может уничтожиться раньше, чем задача закончится. У пользователя может быть несколько сессий, если, допустим, решит с разных машин зайти (почему бы и нет?). Не трогайте сессии. Если вы что-то запишете в сессию, то MVC все обращения к контроллерам, пишущим в сессию, будет обрабатывать последовательно (чтобы не было racing), а это положит производительность на лопатки. Это известная проблема.

Пишите прогресс в базу и не страдайте фигнёй. Детализировать процесс до долей процента смысла не имеет никакого от слова совсем. Либо используйте набор состояний "ещё не начато, начато, закончено", либо, если уж так хочется, то проценты с шагом в десятку. База такое выдержит играючи. Никаких блокировок тут не будет и в помине.

Добавлено через 1 минуту
К тому же, сессия - аспект ASP.NET MVC, а работа с 1С к этому вообще отношения не должна иметь. Получается, что вы вообще всё, что только возможно в одну кучу сваливаете (долгая работа в контроллере, сессия, импорт чего-то в 1С). Хуже и придумать нельзя.

1

Сообщение от Usaga либо, если уж так хочется, то проценты с шагом в десятку. База такое выдержит играючи. Никаких блокировок тут не будет и в помине.

Вью не знает про сервис. Ей всё равно "в десятку" оно или нет. Он будет каждые ХХ секунд запросы отправлять. А значит он всё равно будет терзать БД ради одной цифры. Конечно БД справится, но ей бы заниматься своим делом, а она ещё должна прогресс обновлять и отдавать.

Я работал с Hangfire. Загружали тысячи файлов. Никто не задумывался про какой-то прогресс. Очень интересно - идёшь в его админку и видишь статус "Запущен, в работе". Всё, сиди и жди. Потом открываешь, видишь что закончился и статус.

Напишите на винформах загрузчик и смотрите на чудесный прогресс бар.

0

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

0

А еще , задача реализованная в отдельной службе/сервисе и т.п. может предоставлять api для мониторинга своей деятельности , по какому нибудь простенькому протокольчику. Все что останется браузеру . через это апи опрашивать службу о ее состоянии и прогрессе.

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

1

Спасибо за советы, приму к сведению. Поскольку задача у меня специфичная то думаю подход я выбрал верный. Мне нужно создать прокладку между двумя системами - по веб апи принимать данные и затем отправлять их же в другую систему. Апи в этом случае пишется для одного пользователя и вряд ли будет запускаться параллельно два и более процесса загрузки или выгрузки одновременно. В случае с загрузкой это в принципе не имеет значения т.к. данные принимаются 1 запись=1запрос, накапливаются в статическом листе и по расписанию пишутся в базу с помощью hangfire. Здесь единственная коллизия которую вижу запуск процесса записи по расписанию во время наполнения статического листа. Тут просто проверяю интервал между текущим временем и последней загрузкой записи. В плане выгрузки(под 1с имел ввиду что принимающая сторона - система 1с, выгрузка также по апи) также сделал при нажатии кнопки на выгрузку создается фоновый процесс hangfire отправляющий данные, он то и посылает с помощью signalr данные для прогресс бара, запускать одновременно несколько выгрузок теоретически возможно, но можно просто запретить это делать, так как никакой практической надобности в этом нет.

0

мммда... вопрос был про progress bar, а закончили архитектурными решениями.
Яндекс выдал эту тему на запрос asp core progress bar, но тут нет ничего про прогресс бар.

0

Чипс, progress bar в браузере - это джава-скриптовый компонент, в какую бы архитектуру его не пихай ...

0