IIS 7: компрессия JSON ответа

в 7:29, , рубрики: .net, ASP, asp.net mvc, iis, json, web.config, Веб-разработка, метки: , , ,

Несколько дней назад мой знакомый обратил внимание, что его большие JSON ответы (порядка 0,5-1 мегабайта) не паковались. Рабочая связка Windows 2008 R2 + IIS 7.5 + ASP.NET MVC 4. Проблема обозначена, начался поиск решения. Чтобы воспроизвести наши действия, для статьи я написал отдельное приложение.

Метод действия

public ActionResult Index()
{
	if (Request.IsAjaxRequest())
	{
		return Json(new {/*большой объем данных*/}, JsonRequestBehavior.AllowGet);
	}
	return View();
}

Представление

<script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.9.0.js"></script>

<script type="text/javascript">
	jQuery(function ($) {
		$.ajax({
			url: '@Url.Action("Index")'
		});
	})
</script>

Первое, что было проверено, HTTP заголовки

IIS 7: компрессия JSON ответа

Со скриншота видно, что идет ajax запрос X-Requested-With: XMLHttpRequest и браузер сообщает что он понимает gzip или deflate заголовком Accept-Encoding: gzip, deflate, на что сервер отвечает json-ом Content-Type: application/json, но без сжатия, так как отсутствует заголовок Content-Encoding

Далее пошла проверка на установленные модули веб сервера Administrative Tools -> Server Manager -> Roles -> IIS

IIS 7: компрессия JSON ответа

Static/Dynamic Content Comprassion установлены. (Хочу обратить внимание, для Windows 7 установка осуществляется через добавление/удаление компонентов)
Далее проверяем, включена ли компрессия для приложения на IIS.

IIS 7: компрессия JSON ответа

IIS 7: компрессия JSON ответа

Если нет, то ставим галочки и применяем изменения. Разрешить компрессию также возможно через web.config

<system.webServer>
  <urlCompression doStaticCompression="false" doDynamicCompression="false" />
</system.webServer>

либо Configuration Editor -> system.webServer -> urlCompression

IIS 7: компрессия JSON ответа

IIS 7: компрессия JSON ответа

IIS 7: компрессия JSON ответа

Кажется уже все в порядке, но IIS как не отдавал Content-Encoding в заголовке ответа так и не отдает.

В ход пошел

<system.webServer>
    <httpCompression>
      <dynamicTypes>
        <add mimeType="application/json" enabled="true" />
        <add mimeType="application/json; charset=utf-8" enabled="true" />        
      </dynamicTypes>
    </httpCompression>
</system.webServer>

и, ура, победа, мы получаем долгожданный Content-Encoding: gzip. Но есть одно очень большое НО. httpCompression секцию можно определить только в applicationhost.config. А значит это, что, либо вы администратор IIS, либо такой вариант вам не подходит (если конечно вы не убедите вашего хостера в обратном).

Предположим, что найденный вариант вам не подходит, а сжимать ответ вам все-таки надо. Что мы имеем по умолчанию в настройках динамической компрессии.

IIS 7: компрессия JSON ответа

Компрессия будет распространятся, к примеру, на text/javascript. Конечно, это больше похоже на хак, но это лучше чем ничего.

Меняем наш метод действия на

public ActionResult Index()
{
	if (Request.IsAjaxRequest())
	{
		return new JsonResult()
		{
			ContentType = "text/javascript",
			ContentEncoding = Encoding.UTF8,
			JsonRequestBehavior = JsonRequestBehavior.AllowGet,
			Data = new {/*большой объем данных*/}
		};
	}
	return View();
}

и при ответе используя функцию $.ajax тут же получаем ошибку парсинга данных. Иными словами теперь мы должны использовать либо $.getJSON, либо явно указывать, что мы ожидаем json.

Представление

<script src="http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.9.0.js"></script>

<script type="text/javascript">
	jQuery(function ($) {
		$.ajax({
			url: '@Url.Action("Index")',
			dataType: 'json',
		});
	})
</script>

И третье решение, которое появилось, но под те задачи не подходило (это не значит, что оно не достойно внимания) – паковать самим.

Привожу пример со стэка, с которым я полностью согласен

public class CompressAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {

        var encodingsAccepted = filterContext.HttpContext.Request.Headers["Accept-Encoding"];
        if (string.IsNullOrEmpty(encodingsAccepted)) return;

        encodingsAccepted = encodingsAccepted.ToLowerInvariant();
        var response = filterContext.HttpContext.Response;

        if (encodingsAccepted.Contains("deflate"))
        {
            response.AppendHeader("Content-encoding", "deflate");
            response.Filter = new DeflateStream(response.Filter, CompressionMode.Compress);
        }
        else if (encodingsAccepted.Contains("gzip"))
        {
            response.AppendHeader("Content-encoding", "gzip");
            response.Filter = new GZipStream(response.Filter, CompressionMode.Compress);
        }
    }
}

Степень сжатия данных

Пока игрались с выше сказанным, была замечена еще одна интересная вещь, сжатый контент в Fiddler распаковывался и самим же фидлером опять паковалсльтат сжатия у фидлера на глаз был на ~10-20% меньше байт. Как найти настройки степени снных для IIS, ума не приложу. Не считая третьего варианта, в котором можно использовать параметр конструкторов CompressionLevel. Может, кто из вас подскажет? Этот момент для себя считаю важным, так как в зависимости от проекта иногда важен объем передаваемого трафика, а иногда наоборот процессорное время.

Буду рад услышать еще варианты решения проблемы, какими бы безумными идеи на первый взгляд не казались.

Автор: smarly_net

Источник

Поделиться

* - обязательные к заполнению поля