solicitação de página Web para o arquivo de descompactação no servidor - ASP.NET

Question

SharpZipLib . Precisamos ser capazes de descompactar arquivos no servidor e colocá-los na pasta separada. O pedido para descompactar um arquivo será de usuário em uma página web. Imagino se os arquivos são grandes o suficiente ele vai levar um longo tempo para descompactar. Não queremos que os usuários sejam presos na página enquanto espera para descompactação para completar a fim de continuar navegando no site.

O que é uma boa maneira de lidar com este cenário: spin off um segmento diferente de cuidar de descompactação de arquivos, criar um serviço do Windows em separado que irá descompactar arquivos, ou .... o que?

O que são prós e contras de fazê-lo via segmento separado ou serviço janela?

Answer 1

Vantagens de um processo separado
Trabalho realizado em um processo separado pode ser dissociado no tempo, assim como fisicamente, e do ponto de vista da segurança, a partir do fluxo de página. Dissociado no tempo: Se você escolher, você pode amortecer os pedidos para coisas unzip até que "mais tarde" quando a carga é menor e quando você tem ciclos de CPU peças para fazê-lo.

Além disso dissociado fisicamente; para um sistema de grande escala, você pode ter vários processos de trabalho, mesmo implantado em várias máquinas independentes, fazendo este trabalho de forma assíncrona, e que a camada de processamento pode ser dimensionado independentemente do processamento de páginas web. Em qualquer sistema há gargalos, ea vantagem de implantações distribuídas é que você pode escalar as cargas de trabalho separados de forma independente, para eliminar de forma mais eficiente gargalos.

Gostaria de dizer, porém, que este último benefício só é útil em sistemas de muito grande porte. Na maioria dos casos, você não vai ter o tipo de volume de transações que se beneficiariam com uma camada de escala física independente. Isto é verdade não apenas de o carga de trabalho, mas de 98% de todas as cargas de trabalho. O princípio YAGNI se aplica a escalabilidade, também.

Física desacoplamento também permite que as cargas de trabalho díspares (fluxo de página e zip unpack) a ser desenvolvida de forma independente. Em outras palavras, supondo que o item de trabalho não era um simples "descompactar um arquivo", mas foi algo mais complexo, com várias etapas e pontos de decisão ao longo do caminho. Desenhando o processador de trabalho em um processo separado permite o fluxo de página a ser construído e testado de forma independente a partir do processamento workitem. Esta pode ser uma boa vantagem se eles têm de evoluir de forma independente.

Esta dissociação física também é bom se workitems vai chegar através de diferentes canais. Suponha que a página web não é o único caminho para um item de trabalho para chegar. Suponha que você tenha uma queda de ftp, um serviço web, ou uma caixa de e-mail monitorado-máquina que também pode receber workitems. Em que casos seria faz sentido ter o physicall processamento workitem dissociado do processamento de páginas web.

Finalmente, essas coisas são dissociados em segurança em tempo de execução. Em algumas implementações de servidor de aplicativos web, regras de segurança proíbem o servidor web de escrita para o disco - servidores web não têm armazenamento em disco gravável. Um processo de trabalho asynch separado pode ser implantado em uma parte separada da rede, com muito espaço de armazenamento e, talvez, é limitado por um conjunto separado de requisitos de segurança. Isto pode ou não ser aplicável a você.

Vantagens de processamento de Listagem
A vantagem de fazer o trabalho em um segmento separado é que é muito mais simples. A dissociação introduz complexidade e custo. Gestão do trabalho em um segmento separado, você não tem qualquer da sobrecarga operacional da gestão de um processo separado, potencialmente, uma máquina separada. Não há nenhuma configuração adicional, nenhuma nova etapa de compilação / implantação. Nenhum backup adicional. Sem identidade de segurança adicional para manter. No intercâmbio de comunicação que se preocupar (além do envio thread).

Você pode optar por ficar um pouco mais sofisticado sobre o processamento workitem e, opcionalmente, fazer o trabalho de forma síncrona quando os olhares ZipFile pequeno o suficiente. Suponha que você estabelecer um limite de tempo de 4 segundos resposta - acima disso, você precisa de carga de trabalho assíncrono, abaixo de 4 segundos, você fazê-lo "inline". Claro que você nunca sabe ao certo quanto tempo um arquivo zip vai demorar, mas você couldd estabelecer uma boa heurística com base no tamanho do arquivo. Essa otimização está disponível para você se você usa um processo externo para o trabalho assíncrono, ou um segmento separado, mas para ser honesto, é mais simples para aproveitar a otimização quando se usa um segmento separado. Menos trabalho adicional para fazer. Portanto, esta é uma vantagem para a abordagem de rosca.

não Diferenciadores
Se você optar por ter um mecanismo de AJAX polling para a notificação de status de item de trabalho, tchapéu iria trabalhar tanto com o processo separado ou segmento separado. Eu não sei como você faria rastreamento de item de trabalho, mas eu suponho que quando um item de trabalho específico (arquivo zip?) É concluída, então você irá atualizar a algum lugar recorde - um arquivo em um sistema de arquivos, uma tabela em um banco de dados . Essa atualização acontece se ele está sendo feito por um fio no mesmo processo, ou por um processo separado (Windows Service). Assim, o cliente AJAX que as pesquisas só vai verificar a tabela db ou sistema de arquivos em qualquer caso, e receberá a notificação de status de item de trabalho da mesma forma, independentemente de sua decisão arquitetura.

Como decidir
A teoria é interessante, mas em última análise, inútil, sem restrições operacionais reais.

Workload é um dos principais itens do mundo real. Você não disse como grande esses arquivos zip são, mas eu estou supondo que eles são "regular tamanho". Algo sobre 4gb ou menos. Normalmente um arquivo zip como que leva 20-60 segundos para desfazer as malas no meu laptop, mas é claro que em um servidor com um sistema de armazenamento real e CPU mais rápido, ele será menor. Você também não caracterizar a concorrência de transações - como muitas dessas coisas estarão acontecendo a qualquer momento. Estou assumindo a simultaneidade não é particularmente alta.

Se for esse o caso, eu iria ficar com a abordagem mais simples fio assíncrona. Você está fazendo isso em ASP.NET, presumo em um sistema operacional de servidor. O CLR tem um bom gerenciamento de threads, e ASP.NET tem boa capacidade de scale-out processo. Assim, mesmo em altas cargas de trabalho, você vai ter boa utilização da CPU e escala, sem uma tonelada de esforço de configuração.

Se os workitems foram já em execução - digamos Vamos na ordem de horas ou mesmo dias, eo tempo era imprevisível (como o fechamento de uma ordem de estoque) - Bem, nesse caso eu inclinar-se para um processo assíncrono. Se a concorrência estava na casa dos milhares por segundo, ou mais uma vez muito imprevisível, que também recomendaria um processo separado. Se os modos de falha eram complexas o suficiente, eu poderia querer os workitems estar em um processo separado apenas para gerenciá-lo. Se o processamento workitem eram susceptíveis de alterar regularmente (adicionando um passo adicional, de acordo com a evolução das condições de negócios), eu poderia querer-lo em um processo separado.

Mas nenhuma dessas coisas parece ser verdade no seu caso - descompactar arquivos zip.

Answer 2

As desvantagens de um segmento separado são:

1. Quando as extremidades de páginas não há nenhuma maneira fácil de obter notificação no que a outra thread está fazendo.
2. A aplicação pode ser reiniciado a qualquer momento.
3. Seria fácil para acidentalmente começar o processo duas vezes se as submete usuário da página duas vezes em rápida sucessão.
4. código multithread é difícil de depuração.

As vantagens de um segmento separado são:

1. Menos de código
2. Fácil de fazer fogo e esquecer, se o usuário não precisa ser notificado quando o concluída descompactar.
3. No trabalho extra para instalar.

As vantagens e desvantagens de um serviço de janelas são mais ou menos o oposto do acima.

Answer 3

Pessoalmente eu ir abaixo da rota de serviço do Windows com mensagens entre eles para o progresso, como o retorno a handle à descompactação que pode ser usado para o status monitor.

No entanto, você pode também penso que talvez spin off um fio de fazê-lo e que terá todo o prazer executar e página retornos.

Answer 4

Gostaria de usar um processo assíncrono que você pode facilmente pesquisar a partir de um AJAX habilitado página. Quando concluída, a parte AJAX da página pode apresentar os detalhes que você normalmente teria apresentado enquanto o usuário esperou processo seja concluído de forma síncrona.