AspBufferlimit dovrebbe mai essere aumentato dal default di 4 MB?

Question

Un collega sviluppatore ha recentemente richiesto che l'AspBufferlimit in IIS 6 sia aumentato dal valore predefinito di 4 MB a circa 200 MB per lo streaming di file zip più grandi.

Avendo lasciato il classico mondo ASP qualche tempo fa, mi grattavo la testa sul perché avresti voluto tamponare un binarywrite e ho semplicemente suggerito un'impostazione Response.Buffer = false. Ma c'è qualche caso in cui avresti davvero bisogno di renderlo 50 volte la dimensione predefinita?

Ovviamente, il consumo di memoria sarebbe la più grande preoccupazione. Ci sono altre preoccupazioni per la modifica di questa impostazione predefinita?

Answer 1

Aumentare il buffer in questo modo è un'idea estremamente cattiva. Consentiresti a ogni visitatore del tuo sito di utilizzare fino a quella quantità di RAM. Se tuo BinaryWrite/Response.Buffer=false La soluzione non lo placa, potresti anche suggerire che chiami Response.Flush() di tanto in tanto. Oppure sarebbe preferibile aumentare la dimensione del tampone.

In effetti, a meno che tu non abbia un'ottima ragione per cui non dovresti nemmeno passare questo attraverso il processore ASP. Scrivilo in un posto speciale sul disco messo da parte per tali cose e reindirizza lì invece.

Answer 2

Uno degli aspetti negativi della disattivazione del buffer (potresti usare il filo ma non capisco perché lo faresti in questo scenario) è che il cliente non impara quale durata il contenuto all'inizio del download. Quindi il dialogo dei browser all'altra estremità è meno significativo, non può dire quanti progressi sono stati fatti.

Un'alternativa migliore (IMO) è scrivere il contenuto desiderato in un file temporaneo (forse utilizzando GUID per il nome del file), quindi inviando un reindirizzamento al client che punta su questo file temporaneo.

Ci sono una serie di ragioni per cui questo approccio è migliore:-

• Il client ottiene buone informazioni sui progressi nella finestra di dialogo Salva o applicazione che riceve i dati
• Alcune applicazioni possono fare buon uso dei recuperati di range di byte che funzionano bene solo quando il server fornisce contenuti "statici".
• Il file temporaneo può essere riutilizzato per soddisfare le richieste da altri client

Ci sono un certo numero di svantaggi però:-

• Se impiega un po 'di tempo per creare il contenuto del file, la scrittura in un file temporaneo può quindi lasciare un po' di latenza prima che i dati vengano ricevuti e aumentano il tempo di download.
• Se è necessaria una forte sicurezza sul contenuto con un file statico in giro può essere una preoccupazione sebbene l'uso di un nome file di guida casuale mitiga un po '
• È necessario alcune pulizie su vecchi file temporanei.