Обработка длительных отчетов

Как насчет отправки отчета пользователю по электронной почте. Все, что должна сделать страница asp, - это отправить запрос на создание отчета и вернуть сообщение о том, что отчет будет отправлен по электронной почте после завершения работы.

Я бы подумал о том, чтобы сделать этот отчет более автономным с точки зрения обработки.

Подобно созданию очереди для размещения запросов отчетов, обработки отчетов оттуда и после завершения, он может отправлять сообщение пользователю.

Возможно, я бы даже создал отдельную службу Windows для обработки очереди.

Отправка Обновлять: пользователю может осуществляться по электронной почте или у них может быть страница «отчетов», где они могут проверять статус своих отчетов и загружать их, если они готовы.

Ваши пользователи могут не принять такой подход, но:

Когда они запрашивают отчет (нажав кнопку, ссылку или что-то еще), вы можете запустить процесс создания отчета в отдельном потоке и перенаправить пользователя на страницу с надписью «Спасибо, ваш отчет будет отправлен по электронной почте. ты через несколько минут ».

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

В качестве альтернативы вы можете войти в IIS и увеличить время ожидания до> 3 минут.

Использование файловой системы здесь, вероятно, будет хорошей ставкой. Имейте запрос, который немедленно возвращает URL-адрес pdf-файла отчета. Затем ваш сервер может либо запустить внешний процесс, либо отправить запрос самому себе для выполнения отчета. Клиент может опросить сервер (используя http HEAD) для PDF-файла по предоставленному URL-адресу. Если вы сделаете имя файла PDF-файла производным от параметров отчета, либо используя хэш, либо напрямую поместив параметры в имя, вы также получите мгновенное кеширование на стороне сервера.

Вот что я бы сделал, если бы мне представили эту проблему:

1- Остановите тайм-аут! Это пустая трата ресурсов. (поднимите значение тайм-аута asp-страниц)

2- Централизуйте весь доступ к базе данных в одной точке, затем соберите статистику о том, какие отчеты были запущены, когда кем и сколько времени это заняло. Выясните, почему это занимает так много времени из-за сложности отчета? диапазон данных? загрузка сервера? (на самом деле вы можете записать это в файл .csv на сервере и периодически импортировать этот файл на сервер sql для последующего анализа).

В конце концов, вам будет проще «кэшировать» отчеты, если вы пройдете через эту единственную точку доступа (например, тот же запрос с той же датой вернет тот же PDF-файл, сгенерированный ранее)

3- Я знаю, что это действительно не вопрос, но пробовали ли вы погрузиться в эти запросы, чтобы понять, почему они так долго выполняются? Может быть, настройка запроса?

4- Электронная почта / SMS / сообщение на экране, когда отчет готов, кажется отличным ... если ваш пользователь обычно отправляет пакет отчета, который должен быть сгенерирован, возможно, в приложении может быть построена небольшая панель, показывающая прогрессирование «их» очереди. Небольшой элемент управления ajax будет периодически обновлять статус. Подсказка: если вы использовали этот центральный доступ к базе данных и у вас достаточно информации о том, что запускается, когда, почему и как долго, вы в конечном итоге сможете приблизительно оценить время, необходимое для запуска отчета.

Если время ответа критически важно, должны ли определенные пользователи быть ограничены диапазоном данных (например, диапазоном дат) в течение нескольких часов дня?

Удачи и, пожалуйста, опубликуйте более подробную информацию о своем сценарии, если вы хотите получить более точные подсказки ...

Лучше всего начать с настройки запроса. Хотя я не знаю, что вы составляете отчет, на самом деле этот шаг не должен занимать так много времени. С другой стороны, плохо выполняющийся запрос может полностью убить вашу производительность.

В зависимости от того, что вы обнаружите при просмотре запроса, вам может потребоваться добавить некоторые индексы или, возможно, даже настроить таблицу для хранения информации для вашего отчета в денормализованном виде, чтобы сделать ее доступной быстрее. Затем эта денормализованная таблица может обновляться (с помощью задания SQL Server) каждый час или с любой частотой, которую диктуют ваши требования (в пределах разумного).

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

Для такой проблемы вам действительно нужно начинать с базы данных, если у вас нет причин подозревать, что ваш отчет генерирует код, являющийся виновником. Существуют различные пластыри, которые вы могли бы использовать, которые могут помочь на некоторое время, но если ваша база данных является основной причиной, эти решения не будут хорошо масштабироваться, и вы, вероятно, столкнетесь с аналогичными проблемами (или хуже) когда-нибудь в будущем. .