Кэширование больших объектов для сайта asp.net

Question

Мы генерируем отчеты в нашем веб-приложении, запрашивая у нашего сервера sql данные, возвращаемые в формате xml, а затем обрабатываем их с помощью xslt для создания окончательного результата.Чтобы ускорить работу системы, мы удалили всю статическую информацию из возвращенного sql xml и кэшировали большой XDocument со всей статической информацией в нем.Непосредственно перед выполнением преобразования xsl мы добавляем XDocument со статической информацией в конец xml, полученного с сервера sql.Статический XDocument составляет около 50 мегагерц, и его сборка с сервера sql занимает много секунд.

Наша проблема в том, что, как только мы начали кэшировать несколько таких больших XDoc, мы достигли предельного размера личных байтов кеша, и кеш былочищено.Перестройка этих XDocuments занимает слишком много времени, пока люди запускают отчеты.Я не пытался сохранить эти XDocs в физический файл, потому что они нужны для каждого запуска отчета, который происходит постоянно в течение дня.

Я думал об установке AppFabric Cache, но я не уверен, что это отличная идеяхранить от 5 до 10 этих больших предметов в нем.

Есть идеи?Если я установлю больше памяти на веб-сервере, будет ли она автоматически доступна для asp.net для увеличения кеша?Я пытался сжать данные перед тем, как сохранить их в кеше (сжатых в 5 раз), но распаковка и повторное анализирование XDocument замедлили работу сервера.

Answer 1

Окончательно, просто сохраните его в файл как есть, а затем перезагрузите его, как есть, потому что все готово Сериализовано.

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

Answer 2

Вы можете сериализовать объект xml в двоичном формате и сохранить его в базе данных, используя varbinary(max). Не уверен насчет производительности, но, возможно, стоит попробовать, потому что это не займет много времени.

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