Нужно ли когда-либо увеличивать AspBufferLimit со значения по умолчанию 4 МБ? - PullRequest
Новая
       26

Нужно ли когда-либо увеличивать AspBufferLimit со значения по умолчанию 4 МБ?

1 голос
/ 16 ноября 2009

Один из разработчиков недавно попросил увеличить AspBufferLimit в IIS 6 со значения по умолчанию 4 МБ до примерно 200 МБ для потоковой передачи больших файлов ZIP.

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

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

Ответы [ 2 ]

2 голосов
/ 16 ноября 2009

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

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

1 голос
/ 17 ноября 2009

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

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

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

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

Есть ряд недостатков: -

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