Должен ли Aspbufferlimit когда -нибудь быть увеличенным с дефолта 4 МБ?

Question

Сотрудник разработчика недавно попросил увеличить Aspbufferlimit в IIS 6 с значения по умолчанию 4 МБ до около 200 МБ для потоковой передачи более крупных zip -файлов.

Покинув классический мир ASP некоторое время назад, я почесал голову относительно того, почему вы хотели бы буферизировать бинарную писательную и просто предложили настройку Response.Buffer = false. Анкет Но есть ли какой -либо случай, когда вам действительно нужно сделать его в 50 раз размером по умолчанию?

Очевидно, что потребление памяти будет самым большим беспокойством. Есть ли другие проблемы с изменением этой настройки по умолчанию?

Answer 1

Увеличение буфера, как это, является чрезвычайно плохой идеей. Вы позволите каждому посетителю ваш сайт использовать до такого количества оперативной памяти. Если твой BinaryWrite/Response.Buffer=false Решение не успокаивает его, вы также можете предложить, чтобы он позвонил Response.Flush() сейчас и потом. Любой будет предпочтительнее увеличения размера буфера.

На самом деле, если у вас нет очень веской причины, вы не должны даже передавать это через процессор ASP. Напишите это в особое место на диске, отложенном для таких вещей и перенаправьте там.

Answer 2

Одним из недостатков отключения буфера (вы можете использовать Flush, но я действительно не понимаю, почему вы делаете это в этом сценарии), является то, что клиент не узнает, какая длина контента в начале загрузки. Следовательно, диалог браузеров на другом конце менее значимый, он не может сказать, сколько прогресса было достигнуто.

Лучшей (IMO) альтернативой является написание желаемого контента во временный файл (возможно, используя GUID для имени файла), а затем отправка перенаправления клиенту, указывающему на этот временный файл.

Есть ряд причин, почему этот подход лучше:-

• Клиент получает хорошую информацию о прогрессе в диалоговом окне «Сохранить» или приложение, получая данные
• Некоторые приложения могут хорошо использовать байтовые избрания, которые хорошо работают только тогда, когда сервер доставляет «статический» контент.
• Временный файл можно повторно использовать для удовлетворения запросов от других клиентов

Есть несколько недостатков, хотя:-

• Если займет некоторое время для создания содержимого файла, написание во временный файл может оставить некоторую задержку до получения данных и увеличения времени загрузки.
• Если требуется сильная безопасность на содержании, имеющем статический файл, лежащий вокруг
• Существует необходимость в какой -то домашнем хозяйстве на старых временных файлах.