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

Question

Прежде всего, я понимаю, что запускать очень большие / длинные отчеты - ужасная идея. Мне известно, что у 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 Кб / страницу. Очень странно. Я также добавлю, что количество записей на странице установлено, за исключением последней страницы в каждой группе, так что это не тот случай, когда на некоторых страницах больше записей, чем на другой.

Answer 1

Мы сузили объем экспорта больших файлов PDF из SSRS и нашли 2 основных виновников

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

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

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

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

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

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

Answer 2

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).

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

Answer 3

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

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