Как доставить большие файлы в ASP.NET Response?

Ответ 1

Хотя правильный способ доставки больших файлов в IIS - это следующий вариант,

• Установите MinBytesPerSecond в Zero в WebLimits (это, безусловно, поможет повысить производительность, так как IIS выбирает закрыть клиентов, поддерживающих соединения KeepAlive с меньшими размерами).
• Выделите больше рабочего процесса в пул приложений, я установил 8, теперь это нужно делать, только если ваш сервер распространяет большие файлы. Это, безусловно, приведет к тому, что другие сайты будут работать медленнее, но это обеспечит лучшие поставки. Мы установили 8, поскольку у этого сервера есть только один веб-сайт, и он просто доставляет огромные файлы.
• Отключение утилизации пула приложений.
• Отключить сеансы
• Оставить буферизацию включен
• Перед каждым из следующих шагов проверьте, истинно ли Response.IsClientConnected, иначе откажитесь и ничего не отправляйте.
• Установить Content-Length перед отправкой файла
• Отметьте ответ
• Записывать в выходной поток и выполнять регулярные интервалы

Ответ 2

Когда вы задали длину содержимого с bufferOutput равным false, то возможная причина сбоя заключается в том, что IIS пытается gzip отправленный вами файл, и, установив Content-Length IIS, он не сможет изменить его на сжатый, и ошибки начинаются (*).

So keep the BufferOutput to false, and second disable the gzip from iis for the files you send - или отключите iz gzip для всех файлов, и вы программно обрабатываете часть gzip, сохраняя вне gzip файлы, которые вы отправляете.

Некоторые аналогичные вопросы по той же причине: Сайт ASP.NET иногда замерзает и/или показывает нечетный текст в верхней части страницы при загрузке на серверах с балансировкой нагрузки

Сжатие HTTP: некоторые внешние скрипты /CSS не декомпрессируются должным образом в течение некоторого времени

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

Последующие действия

Если бы не gziped, следующее, что мне пришло в голову, это то, что файл отправлен и по какой-то причине соединение задерживается, и получил тайм-аут и закрыт. Таким образом, вы получаете "Remote Host Closed The Connection".

Это можно решить в зависимости от причины:

• Клиент действительно закрыл соединение
• Тайм-аут выполняется из самой страницы, если вы используете обработчик (опять же, вероятно, сообщение должно быть "Тайм-аут страницы" ).
• Тайм-аут исходит из ожидания ожидания, страница занимает больше времени выполнения, получает тайм-аут и закрывает соединение. Возможно, в этом случае сообщение было отключено.
• Пул сделает переработку в момент отправки файла. Отключите все повторные циклы! Это самые возможные случаи, о которых я могу сейчас подумать.

Если он исходит из IIS, перейдите к свойствам веб-сайта и убедитесь, что вы установили самый большой "Тайм-аут подключения" и "Включить HTTP-Keep-Alives".

Тайм-аут страницы, изменив файл web.config(вы можете изменить его программно только для одной конкретной страницы)

<httpRuntime executionTimeout="43200"

Также посмотрите: http://weblogs.asp.net/aghausman/archive/2009/02/20/prevent-request-timeout-in-asp-net.aspx

Замок сеанса

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

некоторый относительный:

вызвать страницу aspx, чтобы вернуть изображение в случайном порядке медленнее

Замена сеанса ASP.Net целиком

Функция Response.WriteFile завершается с ошибкой и дает 504 тайм-аут шлюза

Ответ 3

Что бы я сделал, это использовать не столь известный ASP.NET Response.TransmitFile, так как он очень быстро (и, возможно, использует Кеш кеша IIS) и заботится обо всех материалах заголовка. Он основан на неуправляемом Windows TransmitFile API.

Но чтобы иметь возможность использовать этот API, вам нужен физический файл для передачи. Итак, вот псевдо-код С#, который объясняет, как это сделать с вымышленным файловым файлом myCacheFilePath. Он также поддерживает возможности кэширования клиентов. Конечно, если у вас уже есть файл под рукой, вам не нужно создавать этот кеш:

    if (!File.Exists(myCacheFilePath))
    {
        LoadMyCache(...); // saves the file to disk. don't do this if your source is already a physical file (not stored in a db for example).
    }

    // we suppose user-agent (browser) cache is enabled
    // check appropriate If-Modified-Since header
    DateTime ifModifiedSince = DateTime.MaxValue;
    string ifm = context.Request.Headers["If-Modified-Since"];
    if (!string.IsNullOrEmpty(ifm))
    {
        try
        {
            ifModifiedSince = DateTime.Parse(ifm, DateTimeFormatInfo.InvariantInfo);
        }
        catch
        {
            // do nothing
        }

        // file has not changed, just send this information but truncate milliseconds
        if (ifModifiedSince == TruncateMilliseconds(File.GetLastWriteTime(myCacheFilePath)))
        {
            ResponseWriteNotModified(...); // HTTP 304
            return;
        }
    }

    Response.ContentType = contentType; // set your file content type here
    Response.AddHeader("Last-Modified", File.GetLastWriteTimeUtc(myCacheFilePath).ToString("r", DateTimeFormatInfo.InvariantInfo)); // tell the client to cache that file

    // this API uses windows lower levels directly and is not memory/cpu intensive on Windows platform to send one file. It also caches files in the kernel.
    Response.TransmitFile(myCacheFilePath)

Ответ 4

Эта часть кода работает для меня. Он немедленно запускает поток данных клиенту. Он показывает прогресс во время загрузки. Он не нарушает HTTP. Контент-длина заголовка указан и кодировка передачи chuncked не используется.

protected void PrepareResponseStream(string clientFileName, HttpContext context, long sourceStreamLength)
{
    context.Response.ClearHeaders();
    context.Response.Clear();

    context.Response.ContentType = "application/pdf";
    context.Response.AddHeader("Content-Disposition", string.Format("filename=\"{0}\"", clientFileName));

    //set cachebility to private to allow IE to download it via HTTPS. Otherwise it might refuse it
    //see reason for HttpCacheability.Private at http://support.microsoft.com/kb/812935
    context.Response.Cache.SetCacheability(HttpCacheability.Private);
    context.Response.Buffer = false;
    context.Response.BufferOutput = false;
    context.Response.AddHeader("Content-Length", sourceStreamLength.ToString    (System.Globalization.CultureInfo.InvariantCulture));
}

protected void WriteDataToOutputStream(Stream sourceStream, long sourceStreamLength, string clientFileName, HttpContext context)
{
    PrepareResponseStream(clientFileName, context, sourceStreamLength);
    const int BlockSize = 4 * 1024 * 1024;
    byte[] buffer = new byte[BlockSize];
    int bytesRead;
    Stream outStream = m_Context.Response.OutputStream;
    while ((bytesRead = sourceStream.Read(buffer, 0, BlockSize)) > 0)
    {
        outStream.Write(buffer, 0, bytesRead);
    }
    outStream.Flush();
}