¿Debería aumentar Aspbufferlimit alguna vez al valor predeterminado de 4 MB?

Question

Un compañero desarrollador solicitó recientemente que el AspBufferlimit en IIS 6 se incrementen del valor predeterminado de 4 MB a alrededor de 200 MB para transmitir archivos zip más grandes.

Habiendo dejado el clásico mundo de ASP hace algún tiempo, me estaba rascando la cabeza sobre por qué querrías amortiguar una escritura binaria y simplemente sugerí un entorno. Response.Buffer = false. Pero, ¿hay algún caso en el que realmente necesite hacer que sea 50 veces el tamaño predeterminado?

Obviamente, el consumo de memoria sería la mayor preocupación. ¿Existen otras preocupaciones para cambiar esta configuración predeterminada?

Answer 1

Aumentar el amortiguador como ese es una idea sumamente mala. Permitiría que cada visitante de su sitio use hasta esa cantidad de RAM. Si tu BinaryWrite/Response.Buffer=false la solución no lo apacigúa, también podrías sugerir que llame Response.Flush() de vez en cuando. Cualquiera de los cuales sería preferible aumentar el tamaño del búfer.

De hecho, a menos que tenga una muy buena razón por la que ni siquiera debe pasar esto por el procesador ASP. Escríbelo en un lugar especial en el disco reservado para tales cosas y redirige allí.

Answer 2

Una de las desventajas de apagar el búfer (podría usar al ras, pero realmente no entiendo por qué lo haría en este escenario) es que el cliente no aprende qué longitud del contenido al comienzo de la descarga. Por lo tanto, el diálogo de los navegadores en el otro extremo es menos significativo, no puede saber cuánto progreso se ha logrado.

Una alternativa mejor (OMI) es escribir el contenido deseado en un archivo temporal (tal vez usando GUID para el nombre del archivo) y luego enviar una redirección al cliente que apunta a este archivo temporal.

Hay varias razones por las cuales este enfoque es mejor:-

• El cliente obtiene una buena información de progreso en el cuadro de diálogo Guardar o la aplicación que recibe los datos
• Algunas aplicaciones pueden hacer un buen uso de las recuperaciones de rango de bytes que solo funcionan bien cuando el servidor está entregando contenido "estático".
• El archivo temporal se puede reutilizar para satisfacer las solicitudes de otros clientes

Sin embargo, hay una serie de inconvenientes:-

• Si se toma en algún momento para crear el contenido del archivo, escribir en un archivo temporal puede dejar cierta latencia antes de que se reciban los datos y aumentar el tiempo de descarga.
• Si se necesita una seguridad fuerte en el contenido de tener un archivo estático, puede ser una preocupación, aunque el uso de un nombre de archivo GUID aleatorio mitiga que algo
• Se necesita una limpieza en archivos temporales antiguos.