Нужно ли когда-либо увеличивать AspBufferLimit со значения по умолчанию 4 МБ?
Один из разработчиков недавно попросил увеличить AspBufferLimit в IIS 6 со значения по умолчанию 4 МБ до примерно 200 МБ для потоковой передачи больших файлов ZIP.
Покинув мир Classic ASP некоторое время назад, я ломал голову над тем, почему вы хотите буферизовать BinaryWrite, и просто предложил установить Response.Buffer = false, Но есть ли какой-то случай, когда вам действительно нужно сделать его в 50 раз больше размера по умолчанию?
Очевидно, что потребление памяти будет самым большим беспокойством. Есть ли другие проблемы с изменением этой настройки по умолчанию?
2 ответа
Подобное увеличение буфера - крайне плохая идея. Вы бы позволили каждому посетителю вашего сайта использовать до этого количества оперативной памяти. Если твой BinaryWrite/Response.Buffer=false решение не умиротворяет его, вы также можете предложить, чтобы он позвонил Response.Flush() сейчас и тогда. Любой из них будет предпочтительнее, чем увеличение размера буфера.
На самом деле, если у вас нет веских причин, вам не следует даже передавать это через процессор asp. Запишите это в специальное место на диске, выделенном для таких вещей, и вместо этого перенаправьте туда.
Один из недостатков отключения буфера (вы можете использовать Flush, но я действительно не понимаю, почему вы это делаете в этом сценарии) заключается в том, что Клиент не узнает, какова длина Контента в начале загрузки. Следовательно, диалог браузера на другом конце не так важен, он не может сказать, насколько достигнут прогресс.
Лучшей альтернативой (IMO) является запись желаемого содержимого во временный файл (возможно, с использованием GUID для имени файла), а затем отправка перенаправления клиенту, указывающего на этот временный файл.
Есть ряд причин, почему этот подход лучше:
- Клиент получает хорошую информацию о ходе выполнения в диалоговом окне сохранения или в приложении, получающем данные.
- Некоторые приложения могут эффективно использовать выборки из байтового диапазона, которые хорошо работают только тогда, когда сервер доставляет "статический" контент.
- Временный файл может быть повторно использован для удовлетворения запросов от других клиентов
Есть ряд недостатков, хотя:-
- Если для создания содержимого файла требуется некоторое время, запись во временный файл может, следовательно, оставить некоторую задержку до получения данных и увеличить время загрузки.
- Если строгая защита необходима для содержимого, имеющего статический файл, может быть проблемой, хотя использование случайного имени файла GUID смягчает это несколько
- Существует необходимость в некоторой уборке старых временных файлов.