Мы предлагаем решение, которое позволяет генерировать файлы PDF из пользовательских источников HTML. Производительность этого решения действительно может привлечь внимание, что мы и делаем в данный момент. Однако из-за того, как генерируется исходный код HTML, мы ограничены тем, что можем изменить.
Так называемые шаблоны (html-файлы) предлагают возможность включать данные из наборов данных, это достижимо с помощью набора правил.
Например:
<html>
<body> <div placeholder-rule="dataset"></div> </body>
</html>
Это простое правило, которое просто загружает элемент, на котором он находится, и дублирует его для каждой записи, найденной в выбранном наборе данных. Таким образом, для каждой записи div будет повторяться.
Вот откуда возникают проблемы с производительностью, у элемента выше также может быть другой набор данных в одном из дочерних узлов. Что повторит процесс и, следовательно, значительно усложнит работу распознавателя.
Шаблон, который должен получить до 50000 страниц, содержит три из этих итераций, что приводит к тому, что код разрешения занимает невероятно много времени.
Код распознавателя перебирает все узлы HTML и заменяет теги-заполнители данными из набора данных.
Мы используем HTML agility pack (HAP), чтобы получить доступ ко всем узлам внутри шаблона. Отладка показала, что HAP постоянно использует около 1,5-2 ГБ ОЗУ во время процесса разрешения, просто для хранения списка узлов и основного узла документа HTML.
Кто-нибудь имеет опыт работы с PDF в подобном контексте? Если да, то как вы справляетесь с производительностью?
Наше текущее решение: генерирование документов, которые считаются большими, генерируется в фоновом режиме на другом сервере, но для этого требуется много вычислительной мощности, а для его завершения требуется много времени.