Есть небольшой самописный rest api. И иногда, пользователю надо запустить одну задачку, которая может выполняться несколько часов.
В добавок к этому, пользователь хочет по запросу получать статус выполнения.
Я могу написать свой класс, который будет выполнять всё необходимое, а могу воспользовться готовым решением(или почти готовым) в виде Worker Service.
Есть ли какая-то принципиальная разница между полностью самописным вариантом и воркером? Или воркер просто удобнее в использовании, так как базовые вещи уже сделаны за тебя?
И есть ли смысл, для двух разнотипных задач, запускать два Worker Service?
Здравствуйте, Lev_Limin, Вы писали:
L_L>Есть небольшой самописный rest api. И иногда, пользователю надо запустить одну задачку, которая может выполняться несколько часов.
L_L>В добавок к этому, пользователь хочет по запросу получать статус выполнения.
L_L>Я могу написать свой класс, который будет выполнять всё необходимое, а могу воспользовться готовым решением(или почти готовым) в виде Worker Service.
L_L>Есть ли какая-то принципиальная разница между полностью самописным вариантом и воркером? Или воркер просто удобнее в использовании, так как базовые вещи уже сделаны за тебя?
L_L>И есть ли смысл, для двух разнотипных задач, запускать два Worker Service?
Вариантов несколько но все они НЕ должны выполняться в том же процессе что и REST API
сделайте отдельный процесс (Worker) в который каким либо образом (через IPC/ БД / создание нового txt/xml файла в папке или каким либо иным образом)передавайте данные для задания которое надо выполнить.
Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI
Статус обработки Wokrer тоже может сбрасывать каждые X секунд/минут в таблицу БД/файл с уникальным идентификатором задания.
Если хочется "заморочиться" то можно повесить RabbitMQ между Asp.NET RestAPI и Worker что бы в одной очереди кидались задания в worker а статус запрашивать через сообщение в другую очередь...
Вобщем как бы не делали это главное что нужно разнести RestAPI который создает задания от worker который их выполняет...
Здравствуйте, Jericho113, Вы писали:
J>Вариантов несколько но все они НЕ должны выполняться в том же процессе что и REST API J>Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI J>Вобщем как бы не делали это главное что нужно разнести RestAPI который создает задания от worker который их выполняет...
А если не разносить, то чем это чревато?
Везде в примерах всё в одном. Понятно, что примеры простенькие, но хотелось бы разобраться.
Здравствуйте, Lev_Limin, Вы писали:
L_L>Здравствуйте, Jericho113, Вы писали:
J>>Вариантов несколько но все они НЕ должны выполняться в том же процессе что и REST API J>>Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI J>>Вобщем как бы не делали это главное что нужно разнести RestAPI который создает задания от worker который их выполняет...
L_L>А если не разносить, то чем это чревато?
L_L>Везде в примерах всё в одном. Понятно, что примеры простенькие, но хотелось бы разобраться.
основная проблема — процесс в котором работает веб-сервер перезапуститься и/или appDomain будет убит и пересоздан. в этом случае задача также прервётся.
но можно настроить чтоб перезапуска небыло, либо например раз в сутки.
у нас для IIS-а настроен рестарт раз в сутки, длинные задачи в этом же процессе, всё норм.
есть совсем долгие задачи которые должны переживать рестарт, их запускаем как подпроцессы через командную строку.
Здравствуйте, MadHuman, Вы писали:
L_L>>Везде в примерах всё в одном. Понятно, что примеры простенькие, но хотелось бы разобраться. MH>основная проблема — процесс в котором работает веб-сервер перезапуститься и/или appDomain будет убит и пересоздан. в этом случае задача также прервётся. MH>но можно настроить чтоб перезапуска небыло, либо например раз в сутки.
Так если не настраивать? У меня asp.net core под линуксом крутятся как сервисы без перезапуска месяцами, пока саму машину не перезапустят
Здравствуйте, Jericho113, Вы писали:
J>Вариантов несколько но все они НЕ должны выполняться в том же процессе что и REST API J>сделайте отдельный процесс (Worker) в который каким либо образом (через IPC/ БД / создание нового txt/xml файла в папке или каким либо иным образом)передавайте данные для задания которое надо выполнить. J>Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI
Здравствуйте, fmiracle, Вы писали:
F>Расскажи подробнее, почему такая категоричность?
Потому что считается, что процесс, обрабатывающий http-запросы, может быть перезапущен в любой момент. Причины, которыми это объясняется, сложно перечислить без матерных слов и переходов на личности. Вкратце — каждая мелкая жаба мнит себя гуглом.
Здравствуйте, fmiracle, Вы писали:
MH>>но можно настроить чтоб перезапуска небыло, либо например раз в сутки.
F>Так если не настраивать? У меня asp.net core под линуксом крутятся как сервисы без перезапуска месяцами, пока саму машину не перезапустят
если не настраивать будет по дефолту. какой он asp.net core — я не знаю. и если не ошибаюсь под asp.net iis — если активности нет, то процесс глушится.
если по дефолту нет перезапусков и это устраивает, ну и хорошо.
в нашем случае по ряду причин надо было чтоб был рестарт сервиса еженочный.
J>>Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI F>Расскажи подробнее, почему такая категоричность?
Имхо, тут больше вопрос надежности.
Что будет, если процесс упадет? Потеряем ли мы при этом задачи? Допустимо ли это?
Что будет если скачкообразно вырастет нагрузка?
Насколько сильно при этом борьба за вычислительные мощности между API и фоновыми задачами повлияет на критерии качества системы
(время отклика, RPS, допустимое время обработки задачи и т.д.)?
Сможем ли мы при необходимости отмасштабироваться: увеличить количество воркеров не трогая API, увеличить кол-во API, не трогая воркеры?
Что будет, если затупит/упадет фоновая задача? Как это повлияет на латентность в API?
Что будет, если хакер положит/задосит API? Повлияет ли это на выполнение фоновых задач, как именно?
И если для вашего кейса все это не важно, то не вижу проблем хоститься внутри единого процесса.
Здравствуйте, RushDevion, Вы писали:
J>>>Ни в коем случае не делайле long running worker в том же процессе что и Asp.NET Core RestAPI F>>Расскажи подробнее, почему такая категоричность?
RD>Имхо, тут больше вопрос надежности. RD>Что будет, если процесс упадет? Потеряем ли мы при этом задачи? Допустимо ли это? RD>Что будет если скачкообразно вырастет нагрузка? RD>Насколько сильно при этом борьба за вычислительные мощности между API и фоновыми задачами повлияет на критерии качества системы RD>(время отклика, RPS, допустимое время обработки задачи и т.д.)? RD>Сможем ли мы при необходимости отмасштабироваться: увеличить количество воркеров не трогая API, увеличить кол-во API, не трогая воркеры? RD>Что будет, если затупит/упадет фоновая задача? Как это повлияет на латентность в API? RD>Что будет, если хакер положит/задосит API? Повлияет ли это на выполнение фоновых задач, как именно?
RD>И если для вашего кейса все это не важно, то не вижу проблем хоститься внутри единого процесса.
Но мы же не знаем потребностей ТС, какие у него нагрузки и задачи, насколько ему вообще все это актуально. А ответ был категоричный — "никогда в рамках этого процесса, только отдельный, можно через файл общаться". Хотя отдельный процесс на той же машине оставляет половину тех же вопросов что выше ты привел — он может и ресурсы всей машины выжрать, увеличив латентность, и упасть сам по себе.
Здравствуйте, fmiracle, Вы писали:
F>Но мы же не знаем потребностей ТС, какие у него нагрузки и задачи, насколько ему вообще все это актуально. А ответ был категоричный — "никогда в рамках этого процесса, только отдельный, можно через файл общаться". Хотя отдельный процесс на той же машине оставляет половину тех же вопросов что выше ты привел — он может и ресурсы всей машины выжрать, увеличив латентность, и упасть сам по себе.
Почитал ответы и посмотрел на задачу. Для моего случая, хватит и всё в одном, но мысль о разнесении вполне здравая и возьму её на карандаш.
Останавливает от разнесения одно — в той системе нет никаких систем сообщений или чего-то подобного, а самому настраивать их нет ни желания, ни времени,
а люди отвечающие за подобные штуки, ответили, что заняты =)
Но у меня будет всего одна такая длительная задача, причём есть ограничение на количество подобных задач.
Есть огромная куча xml, которая обновляется раз в месяц. Её надо распарсить и положить в базу. Есть консольная утилита,
которая делает такое за несколько часов. Она тоже может прерваться по некоторым причинам, потому она постоянно хранит состояние, что сделано и что осталось.
В остальное время, люди будут грузить по одной xml, и нагрузка не будет большой, может пара сотен в день.
Здравствуйте, Lev_Limin, Вы писали:
L_L>Почитал ответы и посмотрел на задачу. Для моего случая, хватит и всё в одном, но мысль о разнесении вполне здравая и возьму её на карандаш. L_L>Останавливает от разнесения одно — в той системе нет никаких систем сообщений или чего-то подобного, а самому настраивать их нет ни желания, ни времени, L_L>а люди отвечающие за подобные штуки, ответили, что заняты =)
L_L>Но у меня будет всего одна такая длительная задача, причём есть ограничение на количество подобных задач. L_L>Есть огромная куча xml, которая обновляется раз в месяц. Её надо распарсить и положить в базу. Есть консольная утилита, L_L>которая делает такое за несколько часов. Она тоже может прерваться по некоторым причинам, потому она постоянно хранит состояние, что сделано и что осталось.
Так значит у тебя уже есть отдельный процесс, который умеет хранить состояние (как раз можно использовать для показа пользователям) и который умеет продолжать работу если сломался?
Ну так значит тебе как раз отдельный процесс использовать и должно быть даже проще всего, раз приложение под него уже фактически есть, хм?
Здравствуйте, fmiracle, Вы писали:
F>Так значит у тебя уже есть отдельный процесс, который умеет хранить состояние (как раз можно использовать для показа пользователям) и который умеет продолжать работу если сломался? F>Ну так значит тебе как раз отдельный процесс использовать и должно быть даже проще всего, раз приложение под него уже фактически есть, хм?
Да, есть. Но пользователям неудобно её использовать. Все хотят, что бы на сайте ткнули иконку и оно само поехало грузить, и только периодически смотреть статус.
А я, с этой частью .net, не очень.
Здравствуйте, Lev_Limin, Вы писали:
L_L>Останавливает от разнесения одно — в той системе нет никаких систем сообщений или чего-то подобного L_L>Её надо распарсить и положить в базу.
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, fmiracle, Вы писали:
MH>>>но можно настроить чтоб перезапуска небыло, либо например раз в сутки.
F>>Так если не настраивать? У меня asp.net core под линуксом крутятся как сервисы без перезапуска месяцами, пока саму машину не перезапустят MH>если не настраивать будет по дефолту. какой он asp.net core — я не знаю. и если не ошибаюсь под asp.net iis — если активности нет, то процесс глушится. MH>если по дефолту нет перезапусков и это устраивает, ну и хорошо. MH>в нашем случае по ряду причин надо было чтоб был рестарт сервиса еженочный.
Здравствуйте, pugv, Вы писали:
P>Если есть БД, чем она не механизм обмена?
Тем, что периодически poll-ить БД — это плохо.
Для этого существуют другие механизмы, типа очередей и/или SignalR.
Здравствуйте, alexanderfedin, Вы писали:
A>Тем, что периодически poll-ить БД — это плохо. A>Для этого существуют другие механизмы, типа очередей и/или SignalR.
Не спорю, хотя с БД есть варианты и без периодического поллинга.
Но у ТС вроде как на этот счёт довольно жёсткие ограничения.
то можно повесить RabbitMQ между Asp.NET RestAPI и Worker что бы в одной очереди кидались задания в worker а статус запрашивать через сообщение в другую очередь... 
