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

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

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

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

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

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

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

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

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

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

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

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

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

EDIT: прочитав сообщение kcrumley, я начал смотреть на средний размер страницы, принимая размер файла / количество страниц. Интересно, что на небольших отчетах математика работает так, что каждая страница составляет примерно 5K. интересно, что когда отчет становится больше, это "average" увеличивается. Отчет на 8000 страниц, например, усредняется по 40K/page. очень странно. Я также добавлю, что количество записей на странице устанавливается за исключением последней страницы в каждой группе, поэтому это не тот случай, когда некоторые страницы имеют больше записей, чем другие.