Оптимизация экспорта PDF огромных отчетов в Sql Reporting Services 2005

Прежде всего, я понимаю, что запускать очень большие / длинные отчеты - ужасная идея. Мне известно, что у Microsoft есть эмпирическое правило, согласно которому отчет SSRS должен выполняться не более 30 секунд. Однако иногда гигантские сообщения являются предпочтительным злом из-за внешних сил, таких как соблюдение законов штата.

У меня по месту работы у нас есть приложение asp.net (2.0), которое мы перенесли из Crystal Reports в SSRS. Из-за большой пользовательской базы и сложных требований к пользовательскому интерфейсу создания отчетов у нас есть набор экранов, который принимает введенные пользователем параметры и создает расписания для запуска в течение ночи. Поскольку приложение поддерживает несколько структур отчетности, мы не используем средства планирования / моментального снимка SSRS. Все отчеты в системе генерируются запланированным консольным приложением, которое принимает введенные пользователем параметры и генерирует отчеты с соответствующими решениями для отчетов, с помощью которых были созданы отчеты. В случае отчетов SSRS консольное приложение генерирует отчеты SSRS и экспортирует их в виде PDF-файлов через API веб-службы SSRS.

До сих пор с SSRS было гораздо проще иметь дело, чем с Crystal, за исключением определенного отчета на 25 000 страниц, который мы недавно преобразовали из отчетов Crystal в SSRS. Сервер SSRS - это 64-битный сервер 2003 года с 32 гигабайтами оперативной памяти, работающий на SSRS 2005. Все наши небольшие отчеты работают фантастически, но у нас возникают проблемы с нашими большими отчетами, такими как этот. К сожалению, мы не можем сгенерировать вышеупомянутый отчет через API веб-службы. Следующая ошибка возникает примерно через 30-35 минут после генерации / экспорта:

Сообщение об исключении: базовое соединение было закрыто: при получении произошла непредвиденная ошибка.

Уверен, что вызов веб-службы вы уже видели раньше:

data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
   selectedParameters, null, null, out encoding, out mimeType, out usedParameters, 
   out warnings, out streamIds);

Странно то, что этот отчет будет запускаться / отображаться / экспортироваться, если отчет запускается непосредственно на сервере отчетов с помощью диспетчера отчетов. Процесс, который создает данные для отчета, работает около 5 минут. Отчет отображается в собственном формате SSRS в браузере / средстве просмотра примерно через 12 минут. Экспорт в pdf через браузер / просмотрщик в диспетчере отчетов занимает дополнительно 55 минут. Это работает надежно, и это дает колоссальный 1,03 ГБ PDF.

Вот некоторые из наиболее очевидных вещей, которые я пытался заставить работать отчет через API веб-сервиса:

  • установите значение HttpRuntime ExecutionTimeout на 3 часа на сервере отчетов
  • отключен http держать живыми на сервере отчетов
  • увеличено время ожидания скрипта на сервере отчетов
  • установить отчет, чтобы никогда не тайм-аут на сервере
  • установить время ожидания отчета на несколько часов на клиентском вызове

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

Исходя из моего исследования сообщения об ошибке, я считаю, что API веб-службы не отправляет фрагментированные ответы по умолчанию. Это означает, что он пытается отправить все 1,3 ГБ по проводам в одном ответе. В определенный момент IIS бросает в полотенце. К сожалению, API абстрагируется от конфигурации веб-службы, поэтому я не могу найти способ включить разбиение ответов.

  1. Кто-нибудь знает в любом случае, чтобы уменьшить / оптимизировать фазу экспорта PDF и / или размер PDF без уменьшения общего количества страниц?
  2. Есть ли способ включить ответный чанк для SSRS?
  3. У кого-нибудь еще есть другие теории относительно того, почему это работает на сервере, а не через API?

РЕДАКТИРОВАТЬ: После прочтения сообщения kcrumley я начал смотреть на средний размер страницы, принимая размер файла / количество страниц. Интересно, что в небольших отчетах математика получается так, что каждая страница составляет примерно 5 КБ. Интересно, что когда отчет увеличивается, это «среднее» увеличивается. Например, отчет на 8000 страниц в среднем составляет более 40 Кб / страницу. Очень странный. Я также добавлю, что количество записей на странице установлено, за исключением последней страницы в каждой группе, так что это не тот случай, когда на некоторых страницах больше записей, чем на другой.

18.08.2008 22:19:16
3 ОТВЕТА
  1. Кто-нибудь знает в любом случае, чтобы уменьшить / оптимизировать фазу экспорта PDF и / или размер PDF без уменьшения общего количества страниц?

У меня есть несколько идей и вопросов:
1. Это графический отчет? Если нет, есть ли у вас таблицы, которые начинаются как текст, но преобразуются в графические объекты с помощью средства визуализации SSRS PDF (проверьте, можете ли вы выделить текст в PDF)? 41 КБ на страницу может быть больше, чем должно быть, а может и нет, в зависимости от того, насколько насыщен ваш отчет. Но у нас были случаи, когда у нас возникали незначительные проблемы с макетом отчета, например, когда из-за обтекания таблицы стекались поля страницы, рендерер SSRS PDF «подбрасывал руки» и отображал таблицу как изображение, а не как текст. , Очевидно, что чем меньше графики в вашем отчете, тем меньше будет размер файла.
2. Есть ли способ, которым вы могли бы легко разбить отчет на части? Например, если это отчет с 10 местоположениями, где за местоположением 1 следует местоположение 2 и т. Д., В вашем окончательном отчете, могли бы вы запустить часть местоположения 1 независимо от части местоположения 2 и т. Д.? Если это так, вы можете объединить 10 вложенных отчетов в один окончательный PDF-файл, используя PDFSharp, после того как вы получите их все. Это приводит к некоторым трудностям с нумерацией страниц, но ничего непреодолимого.

3. Есть ли у кого-нибудь еще теории о том, почему это выполняется на сервере, а не через API?

Мое предположение было бы огромным размером отчета. Я не помню все, что такое настройка IIS и что специфично для SSRS, но могут быть общие настройки IIS (возможно, в Metabase.xml), которые вам придется обновить, чтобы пропустить столько данных.

Вы могли бы изолировать вопрос о том, является ли время проблемой, взяв один из ваших рабочих отчетов и создав длительное время ожидания в ваших хранимых процедурах с WAITFOR (предполагая, что SQL Server для вашей СУБД).

Не решения как таковые, а идеи. Надеюсь, это поможет.

3
19.08.2008 18:49:15

Очевидно, это огромный отчет, фактически он ближе к базе данных объемом 1,3 ГБ, чем отчет.

Задумывались ли вы о том, чтобы найти способ разбить его на несколько частей, а затем объединить их вместе? (используйте один из нескольких различных способов объединения PDF-файлов, перечисленных на этом сайте.)

2
9.07.2009 15:06:41

Мы сузили крупный экспорт PDF из SSRS и нашли 2 главных виновников

1) Если изображения не являются цветными типами JPG или PNG 3, они расширяются до BMP. Смотрите здесь

2) Если SSRS не настроен на другое поведение (не рекомендуется), SSRS будет встраивать шрифты или подмножества шрифтов в PDF, если только они не являются одним из 5 «стандартных» шрифтов PDF .

Хотя ни один из стандартных шрифтов (кроме Symbol, я полагаю) не установлен в большинстве операционных систем Windows из коробки, мы обнаружили, что если вы используете, Times New Roman, Courier New, or Arialто произойдет прямая и обратная замена шрифтов.

Самый простой способ конвертировать ваши RDL - это просматривать их как XML, искать и заменять FontFamilyтеги.

Если вам нужно использовать нестандартный шрифт, то вы все равно можете минимизировать ущерб:

  • Используйте как можно меньше шрифтов. Выполните поиск по RDL XML, чтобы убедиться в отсутствии лишних шрифтов.
  • Используйте шрифты TTF, если вы используете разные размеры шрифта.
  • Старайтесь не смешивать обычный, жирный и курсивный варианты шрифта, иначе он будет вставлен несколько раз.
4
7.05.2012 12:05:22