При запуске Fiddler я заметил что-то странное в запросе статического XML-файла размером ~ 5 МБ на мой сервер: несмотря на отправку байтовых идентичных заголовков (Edit: включая заголовки), ответы были разными:
Ответ A:
1. 700 КБ содержимого gzip.
2. Включен заголовок Content-Length.
3. Исключенный заголовок Transfer-Encoding.
Ответ B:
1. 1000 КБ содержимого gzip.
2. Исключен заголовок Content-Length.
3. Включен заголовок Transfer-Encoding: фрагментированный заголовок.
Что я могу сделать, чтобы постоянно получать более эффективное использование полосы пропускания, показанное в ответе A?
Необработанный запрос:
GET http://[REDACTED]/[REDACTED]/[REDACTED]/[REDACTED].xml?dt=Test1 HTTP/1.1
Host: [REDACTED]
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Необработанный ответ A:
HTTP/1.1 200 OK
Content-Type: text/xml
Content-Encoding: gzip
Last-Modified: Tue, 07 May 2013 04:04:01 GMT
Accept-Ranges: bytes
ETag: "80ceefe7d74ace1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 07 May 2013 21:07:21 GMT
Content-Length: 728105
[700KB GZipped Body]
Необработанный ответ B:
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/xml
Content-Encoding: gzip
Last-Modified: Tue, 07 May 2013 04:04:01 GMT
Accept-Ranges: bytes
ETag: "60be30e8d74ace1:0"
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Tue, 07 May 2013 21:07:14 GMT
[1MB Gzipped Body]
Сжатие статических файлов выполняется динамически (если включено динамическое сжатие), пока файл считается нечасто пользователя IIS. Как только файл будет рассмотрен частый он будет сжат и кэширован (если включено статическое сжатие). Кешированная версия будет обслуживаться до тех пор, пока она снова не станет редкой. В IIS есть 2 параметра конфигурации, которые можно использовать для настройки часто используемых файлов:
system.webServer / serverRuntime:
frequentHitThreshold: Сколько раз следует запрашивать один и тот же файл, прежде чем он будет считаться частым и кешированным? По умолчанию 2.frequentHitTimePeriod: Интервал времени, в течение которого один и тот же файл должен быть запрошен {частоHitThreshold} раз для кэширования. По умолчанию 10 секунд.Имейте в виду, что независимо от установленного вами параметра partialHitTimePeriod, часто используемый файл всегда будет редким, если он не будет запрошен через 1 минуту. Понятия не имею, есть ли для этого настройка в конфигурации.
Настройка frequentHitThreshold к 1, например, будет означать, что IIS всегда считает файл часто используемым, даже с первого запроса. Это, в свою очередь, обходит динамическое сжатие и лечится только статическим сжатием.
Обратите внимание, что уровни сжатия для динамического (по умолчанию 0) и статического (по умолчанию 7) сжатия различаются, поэтому будет возвращено 2 разных размера файла.
Кроме того, именно поэтому я в первую очередь столкнулся с этой проблемой: ETag для одного и того же файла отличается при динамическом и статическом сжатии, даже если вы используете одинаковые уровни для обоих.
Надеюсь это поможет.
По-видимому, при первом запросе статического файла IIS не имеет сжатой копии файла в кэше сжатого файла, поэтому он использует динамическое сжатие для этого запроса. Это можно решить, установив serverRuntime элемент frequentHitTHreshold атрибут 1.
Это подробно обсуждается Вот. Этот параметр, вероятно, стоит изменять только при обслуживании CDN.
Подробнее о динамическом сжатии IIS см. Здесь:
http://www.west-wind.com/weblog/posts/2011/May/05/Builtin-GZipDeflate-Compression-on-IIS-7x
Обычно при высокой загрузке процессора на сервере выполняется меньшее сжатие
Здесь более подробно и как настроить уровни сжатия:
http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx