O aspbufferlimit deve precisar ser aumentado do padrão de 4 MB?
-
20-09-2019 - |
Pergunta
Recentemente, um colega desenvolvedor solicitou que o aspbufferlimit no IIS 6 aumentasse do valor padrão de 4 MB para cerca de 200 MB para transmitir arquivos ZIP maiores.
Tendo deixado o mundo clássico do ASP há algum tempo, eu estava coçando a cabeça sobre o motivo pelo qual você gostaria de amortecer um binarywrite e simplesmente sugerir configurar Response.Buffer = false
. Mas há algum caso em que você realmente precise fazer com que 50x o tamanho padrão?
Obviamente, o consumo de memória seria a maior preocupação. Existem outras preocupações em alterar essa configuração padrão?
Solução
Aumentar o buffer como esse é uma ideia extremamente ruim. Você permitiria que todos os visitantes do seu site usassem até essa quantidade de RAM. Se seu BinaryWrite/Response.Buffer=false
Solução não opaziguará -lo, você também pode sugerir que ele ligue Response.Flush()
agora e depois. Ou seria preferível aumentar o tamanho do buffer.
De fato, a menos que você tenha um bom motivo, nem deve passar isso pelo processador ASP. Escreva para um local especial no disco reservado para essas coisas e redirecionar para lá.
Outras dicas
Uma das desvantagens de desligar o buffer (você pode usar o Flush, mas eu realmente não entendo por que você faria isso nesse cenário) é que o cliente não aprende o que o comprimento do conteúdo no início do download. Portanto, a caixa de diálogo dos navegadores do outro lado é menos significativa, não pode dizer quanto progresso foi feito.
Uma alternativa melhor (IMO) é escrever o conteúdo desejado em um arquivo temporário (talvez usando o GUID para o nome do arquivo) e depois enviar um redirecionamento para o cliente apontando para este arquivo temporário.
Existem várias razões pelas quais essa abordagem é melhor:-
- O cliente obtém boas informações de progresso na caixa de diálogo Salvar ou no aplicativo recebendo os dados
- Alguns aplicativos podem fazer bom uso de buscas de bytes que funcionam bem quando o servidor está entregando conteúdo "estático".
- O arquivo temporário pode ser reutilizado para satisfazer solicitações de outros clientes
Existem várias desvantagens:-
- Se levar algum tempo para criar o conteúdo do arquivo, a gravação de um arquivo temporário pode, portanto, deixar alguma latência antes que os dados sejam recebidos e aumentando o tempo de download.
- Se for necessária uma segurança forte no conteúdo que tem um arquivo estático por aí pode ser uma preocupação, embora o uso de um nome de arquivo de GUID aleatório atenue isso um pouco
- Há necessidade de algumas tarefas domésticas em arquivos temporários antigos.