L'aspbufferlimit devrait-il jamais être augmenté par rapport à la valeur par défaut de 4 Mo?

Question

Un collègue développeur a récemment demandé que l'AspbufferLimit dans IIS 6 soit augmenté de la valeur par défaut de 4 Mo à environ 200 Mo pour le diffusion de fichiers zip plus importants.

Après avoir quitté le monde de l'ASP classique il y a quelque temps, je me grattrais la tête pour expliquer pourquoi vous voudriez tamponner une écriture binaire et simplement suggérer le réglage Response.Buffer = false. Mais y a-t-il un cas où vous auriez vraiment besoin de faire 50x la taille par défaut?

De toute évidence, la consommation de mémoire serait la plus grande inquiétude. Y a-t-il d'autres préoccupations concernant la modification de ce paramètre par défaut?

Answer 1

Augmenter le tampon comme ça est une idée suprêmement mauvaise. Vous autorisez chaque visiteur à votre site à utiliser jusqu'à cette quantité de RAM. Si ton BinaryWrite/Response.Buffer=false La solution ne l'apaise pas, vous pourriez également suggérer qu'il appelle Response.Flush() de temps en temps. L'un ou l'autre serait préférable à l'augmentation de la taille du tampon.

En fait, à moins que vous n'ayez une très bonne raison, vous ne devriez même pas passer cela par le processeur ASP. Écrivez-le à un endroit spécial sur disque réservé pour de telles choses et redirigez-vous à la place.

Answer 2

L'un des inconvénients de la désactivation du tampon (vous pouvez utiliser Flush mais je ne comprends vraiment pas pourquoi vous le feriez dans ce scénario) est que le client n'apprend pas la longueur du contenu au début du téléchargement. Par conséquent, la boîte de dialogue des navigateurs à l'autre extrémité est moins significative, il ne peut pas dire combien de progrès a été réalisé.

Une meilleure alternative (IMO) consiste à écrire le contenu souhaité dans un fichier temporaire (peut-être en utilisant GUID pour le nom de fichier) puis à envoyer une redirection vers le client pointant sur ce fichier temporaire.

Il y a un certain nombre de raisons pour lesquelles cette approche est meilleure: -

• Le client obtient de bonnes informations de progression dans la boîte de dialogue Save ou l'application recevant les données
• Certaines applications peuvent faire bon usage des récupérations de plage d'octets qui ne fonctionnent bien que lorsque le serveur fournit du contenu "statique".
• Le fichier temporaire peut être réutilisé pour satisfaire aux demandes d'autres clients

Il y a cependant un certain nombre d'inconvénients: -

• Si prend un certain temps pour créer le contenu du fichier, l'écriture dans un fichier temporaire peut donc laisser une latence avant la réception des données et augmenter le temps de téléchargement.
• Si une forte sécurité est nécessaire sur le contenu d'avoir un fichier statique qui traîne peut être une préoccupation bien que l'utilisation d'un nom de fichier de GUID aléatoire atténue quelque peu
• Il est nécessaire de faire du ménage sur les anciens fichiers temporaires.