Estamos lidando com um problema interessante no StackOverflow.
Temos um monte de pequenas tarefas "precisam ser feitas em breve". Um exemplo está atualizando as listas "Perguntas relacionadas". O que fizemos no passado é retroceder essas tarefas nas cargas de página de alguns usuários.
Isso nunca foi o ideal, mas não era realmente perceptível. Agora que o SO ultrapassou os 1.000.000 pontos de interrogação, esses infelizes usuários estão começando a sentir isso.
A solução natural é realmente colocar essas tarefas em segundo plano. Estou pensando em duas maneiras amplas de fazer isso.
1. No IIS como um Thread-Pool / Work-Queue personalizado
Basicamente, criamos alguns threads (não ThreadPool , para não interferir no IIS) e os serviços de algumas coleções nas quais estamos inserindo Funcs .
O grande profissional aqui é a simplicidade. Não precisamos nos preocupar em organizar nada, nem precisamos garantir que algum serviço externo esteja pronto e respondendo.
Também temos acesso a todo o nosso código comum.
O golpe é, bem, que não devemos usar threads de segundo plano. As objeções que eu conheço estão todas centradas no IIS faminto (se você usa o ThreadPool) e os threads morrem aleatoriamente (devido à reciclagem do AppPool).
Temos a infraestrutura existente para tornar a morte aleatória do encadeamento um problema (é possível detectar uma tarefa foi basicamente abandonada) e limitar o número de encadeamentos (e usar encadeamentos que não sejam do ThreadPool) também não é difícil.
Movido para StackOverflow , pois não foi realmente abordado aqui.
2. Como serviço
Alguma solução de terceiros ou uma solução personalizada.
Basicamente, organizávamos uma tarefa através do limite do processo para algum serviço e simplesmente a esquecíamos. Presumivelmente, estamos vinculando algum código ou restritos ao SQL bruto + uma cadeia de conexão.
O profissional é que é o "caminho certo" para fazer isso.
Os contras são que somos muito restritos no que podemos fazer ou teremos que elaborar algum sistema para manter esse serviço sincronizado com nossa base de códigos. Também precisamos conectar todo o nosso monitoramento e registro de erros de alguma forma, que obtemos gratuitamente com a opção "No IIS".
Existem outros benefícios ou problemas com a abordagem de serviço?
Em poucas palavras, existem problemas imprevisíveis e intransponíveis que tornam a abordagem nº 1 impraticável? Em caso afirmativo, existem bons serviços de terceiros nos quais devemos procurar a abordagem nº 2?