Нагрузочное тестирование

[DmitryRu]

Дальнейшее изучение проблемы показывает, что запрос отчета в браузерах Firefox и Chrome выглядит так

network.png (21.13 КБ) 4386 просмотров

Первый запрос, это запрос HTML разметки странички с отчетом, вида:
http://172.19.16.83/MC/StiView/ShowRepo ... %3A00%3A00
(На всякий случай напомню, что в моем случае, параметры отчета передаются в виде параметров GET запроса странички с отчетом)
Далее идут 2 запроса, запрашиваются js и css:
http://172.19.16.83/MC/StiView/ViewerEv ... v=2015.1.0
http://172.19.16.83/MC/StiView/ViewerEv ... v=2015.1.0
Далее идет запрос данных для отчета:
http://172.19.16.83/MC/StiView/GetRepor ... %3A00%3A00

Fidder по поводу этих запросов js и css пишет следующее:

HTTP/200 responses are cacheable by default, unless Expires, Pragma, or Cache-Control headers are present and forbid caching.
HTTP/1.0 Expires Header is present: Пт, 13 май 2016
HTTP/1.1 Cache-Control Header is present: private, s-maxage=0
private: This response MUST NOT be cached by a shared cache.
This response contains neither an ETAG nor a Last-Modified time. This will prevent a Conditional Revalidation of this response.
================
Learn more about HTTP caching at http://www.fiddler2.com/r/?id=httpperf

Собственно, самое печальное в моей ситуации, что запросы javascript и css не кэшируются, они запрашиваются при каждом построении отчета. А это, как мы видим из картинки, 275 и 15 кб соотвественно. Их реально надо запрашивать при каждом построении отчета? Можно ли как-то настроить их кэширование?

На всякий случай напомню, что в моем случае, параметры отчета передаются в виде параметров GET запроса странички с отчетом. Но для запроса именно .css и js файлов эти параметры уж наверняка не нужны....

[DmitryRu]

Возможно, данная проблема связана с тем, что в нашем приложении, отчет всегда открывается в новой вкладке браузера.
Так сложилось исторически, может быть, при использовании библиотек Stimulsoft это не лучшая идея.....

[DmitryRu]

Проблема с этими 4мя довольно большими запросами в том, что в нашем случае, при высокой нагрузке на приложение, каждый http запрос выполняется по 1 - 1.5 сек, и если можно было бы избавиться от хотя бы от запросов 2 и 3 (js и css), то тогда мы могли бы обогнать по скорости SSRS сервер.

Еще хотелось бы уточнить следующее

1) Первый запрос, запрос html странички, содержит в себе довольно оригинально зашифрованные картинки в Base64. Эти картинки занимают довольно значительный объем, есть ли возможность вынести эти картинки в отдельный sprite, который уже может быть закэширован?
2) Может быть, эти картинки вычисляются каждый раз при запросе .cshtml странички?
3) Запросы 2 и 3, а именно js и .css - результаты выполнения этих запросов как-то кэшируются Вашим кодом, или каждый раз вычисляются?

[Vladimir]

Здравствуйте Дмитрий,

По поводу параметров в URL.
Запросы скриптов и стилей обрабатывает действие ViewerEvent. В этом действии иногда бывает необходимость проверки каких-либо пользовательских параметров (нам присылали такого рода проекты), так что передачу параметров полностью вырезать нельзя. Мы можем сделать специальную опцию, которая будет отключать передачу сторонних параметров, скорее всего это решит проблему с кэшированием.

По поводу последних вопросов:
1) Картинки передаются с сервера в base64 кодировке с целью прямой вставки в IMG как data url. Также, base64 кодировка изображений используется на страницах отчета (если в отчете присутствуют изображения). Это позволяет решить ряд проблем, включая проблему множественных запросов на сервер и некоторые вопросы с темированием вьювера. Ваше пожелание передано разработчикам, в следующем обновлении попробуем загрузить картинки и локализацию как отдельный .js файл (с включенным кэшированием).
2) Сами картинки и их количество зависят от выбранной темы вьювера.
3) Эти файлы каждый раз берутся из ресурсов (они хранятся как множество отдельных скриптов и стилей), программно обрабатываются, складываются в два файла и передаются клиенту с заголовком "Cache-Control: public, max-age=31536000", и если параметры URL не изменяются - кэширование должно работать. Как сказано выше - мы сделаем опцию, которая позволит отключить передачу сторонних параметров для кэшируемых ответов.

Спасибо за подробный отчет о работе вьювера.

[DmitryRu]

Спасибо за обратную связь.
Да, нам была бы интересна опция, которая позволила бы не передавать в метод контроллера ViewerEvent параметры, которые были в изначальном URL.
По возможности, дайте ориентир по времени, когда такая появится.

Дальнейшие изыскания показали следующее.
В дефолтной настройке StiMvcViewer в классе StiFileResult параметры кэширования задаются так:

Код: Выделить всё

      if (this.EnableBrowserCache)
      {
        response.AddHeader("Cache-Control", "public");
        response.AddHeader("Expires", DateTime.Now.AddYears(1).ToString("ddd, dd MMM yyyy"));
      }

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

russian.png (39.02 КБ) 4376 просмотров

Проблема обведена красным. Собственно, проблема в том, что при таком Expires англоязычный Firefox не кэширует данные.
На мой взгляд, корректнее было бы писать:

Код: Выделить всё

            Response.Cache.SetExpires(DateTime.Now.AddYears(1));

Результат такого подхода:

englsih.png (7.58 КБ) 4376 просмотров

[Vladimir]

Здравствуйте Дмитрий,

Дальнейшие изыскания показали следующее.
В дефолтной настройке StiMvcViewer в классе StiFileResult параметры кэширования задаются так:

Формирование заголовков уже исправлено, теперь заголовок устанавливается следующим образом:

Код: Выделить всё

    if (EnableBrowserCache) response.AddHeader("Cache-Control", "public, max-age=31536000");

В этом случае, проблем с браузерами быть не должно. Так же, в обновленном варианте устранена проблема в случае некорректно установленной даты на сервере.


Опция, которая позволит отключить передачу query параметров в запросы, ответы которых должны кэшироваться, будет называться PassQueryParametersForResources в группе Server. Обновление будет доступно в следующем пререлиз билде завтра, 15 мая.

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

Спасибо.

[DmitryRu]

Спасибо за участие!

Вообще, мне кажется, идея дать директиву "время жизни в кэше == 1 год" - не лучшая идея.
А что, если в течении этого года, пользователи захотят поменять, допустим, тему вьювера?
Ведь как минимум, .css, мне кажется, зависит от выбранной темы?
Может, стоить сделать опцию, если она не установлена, кэшируем на год, но пользователь может задать свое значение.

А также хозяйке на заметку.
Если метод ViewerEvent помечен атрибутом [Authorize], то данный атрибут сбрасывает, как минимум, настройку Cache-Control: public на private, подробнее здесь
http://stackoverflow.com/questions/3445 ... sp-net-app

Кроме того, возможно, стоит метод ViewerEvent пометить атрибутом OutputCache, чтобы он кэшировался и сервером.

[Vladimir]

Здравствуйте Дмитрий,

Вообще, мне кажется, идея дать директиву "время жизни в кэше == 1 год" - не лучшая идея.
А что, если в течении этого года, пользователи захотят поменять, допустим, тему вьювера?
Ведь как минимум, .css, мне кажется, зависит от выбранной темы?
Может, стоить сделать опцию, если она не установлена, кэшируем на год, но пользователь может задать свое значение.

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

А также хозяйке на заметку.
Если метод ViewerEvent помечен атрибутом [Authorize], то данный атрибут сбрасывает, как минимум, настройку Cache-Control: public на private, подробнее здесь
http://stackoverflow.com/questions/3445 ... sp-net-app

Кроме того, возможно, стоит метод ViewerEvent пометить атрибутом OutputCache, чтобы он кэшировался и сервером.

Действие ViewerEvent используется не только для получения скриптов и стилей. Оно используется, например, для листания страниц, изменения масштаба, а так же по умолчанию для печати, экспортирования и применения параметров отчета, если не заданы соответствующие действия. Эти данные нет смысла кэшировать.

Спасибо.

[DmitryRu]

Большое спасибо за консультации и быструю обратную связь!

Мы протестировали версию 2015.1.4.0, она работает в 2 раза быстрее, чем наши текущие отчеты на SSRS сервере.

Правда, надо сделать оговорку - мы тестируем вариант "много пользователей одновременно строят много маленьких отчетов". Стимулсофт выигрывает за счет того, что мы добились, чтобы на построение отчета уходило всего 2 HTTP запроса (еще 2 запроса, со скриптами и .css, кэшируются браузером).
SSRS же делает от 5 до XX запросов на отчет (где XX зависит от количества параметров типа "время" у отчета), и я не могу от микрософта добиться уменьшения кол-ва HTTP запросов.

Т.е. на большом отчете все-таки видно, что непосредственно построение схожего отчета SSRS делает быстрее - например, отчет на 140 страниц Стимулсофт строит за 20 сек, а SSRS - за 16.

Но Ваше уменьшение кол-ва HTTP запросов, и одновременно, что картинки переехали в кэшируемые запросы, существенно подняли скорость работы приложения в более важном сценарии - много "быстрых" отчетов.

С уважением,
Дмитрий.

[HighAley]

Здравствуйте.

Спасибо за ваш интерес к нашему продукту. Вы помогаете делать его ещё лучше.
Мы всегда рады вам помочь.
Если у вас будут ещё предложения по оптимизации -- пишите, мы сделаем всё возможное, чтобы это реализовать.

Спасибо.