Um Agendador vs. Muitos Agendadores

5

Eu tenho usado um único agendador para lidar com todas as minhas tarefas agendadas (Quartz.Net). Estou começando a repensar como isso funciona, porque se eu precisar atualizar uma tarefa, terei que interromper todo o processo, liberar a atualização e iniciá-la novamente.

Minha pergunta: É melhor ter muitos serviços do Windows executando tarefas individuais (ou grupos de tarefas semelhantes) ou 1 serviço executando todas as tarefas (minha configuração atual)?

    
por MattB 02.08.2013 / 18:13
fonte

2 respostas

1

Eu passei um pouco de tempo recentemente com o Quartz.NET e posso compartilhar algumas das experiências que tivemos. Meu cenário cobria um único processo (serviço do windows) que era responsável por atualizar o agendamento existente (usando detalhes baixados como XML de um servidor). O processo de serviço também cobriu a maior parte da funcionalidade que poderia ser acionada.

Acho que o fator chave aqui é o que você entende por "atualizar" uma tarefa. Você quer dizer simplesmente alterar detalhes de agendamento (que tarefas executar, quando executá-las, etc.) ou os binários reais envolvidos na execução da tarefa? Se você está esperando atualizações frequentes para binários e recursos, provavelmente um modelo monolítico único não é adequado para você. Se você está esperando apenas atualizações frequentes sobre quando e qual tarefa deve ser executada, vale a pena centralizar o gerenciamento das tarefas e o agendamento.

Os grupos de acionadores funcionam bem para dividir e gerenciar vários tipos de trabalho. Isso torna o CRUD contra o cronograma de memória muito mais limpo. Por exemplo, você pode obter todos os trabalhos em um grupo com bastante facilidade

    
por 19.08.2013 / 07:34
fonte
0

Eu nunca usei o Quartz.NET, mas achei que ele estava configurado para permitir que você modificasse as configurações de trabalho simplesmente editando um arquivo de configuração e / ou soltando uma nova DLL, e as alterações seriam apanhadas imediatamente. / p>

Se esse não é o caso, então algo assim parece ser uma boa abordagem para mim. Por exemplo, você pode ter uma DLL separada para cada tarefa, com uma classe que implemente uma interface comum. Quando uma tarefa é programada para disparar, carregue dinamicamente a DLL, use a reflexão para recuperar uma instância da tarefa e execute-a. Então, se você precisar alterar um trabalho, basta inserir uma nova DLL e, na próxima vez que for escolhida, será o novo código.

    
por 08.08.2013 / 17:56
fonte

Tags