Marklogic xslt 性能答案

【问题标题】：Marklogic xslt performanceMarklogic xslt 性能
【发布时间】：2015-11-04 20:28:16
【问题描述】：

我有一个 XSLT，我正在通过 xdmp:invoke() 函数执行它，我遇到了很长的处理时间才能看到任何结果（在某些情况下，在达到 3600 秒的最大时间后完全超时）。这个 XSLT 在 Oxygen 编辑器中运行大约需要 5 秒。我认为可能会影响性能的一些领域：

XSLT 使用xsl:result-document 生成多个输出文件。 MarkLogic XSLT 处理器将这些作为结果 XML 节点输出，因为它无法将这些文档物理地保存到文件系统中。
XSLT 构建包含 xml 节点的变量，然后由其他模板调用处理这些变量。有时，这些变量可以包含大量 XML 节点。

我对 XSLT 进行了一些分析，似乎构建变量似乎是执行过程中最耗时的部分。我想知道为什么会这样，为什么它在撒克逊处理器上运行得更快？

非常感谢任何见解。

【问题讨论】：

当前在 Linux 服务器上运行 Marklogic (Marklogic 7.0-4.1)

标签： xslt marklogic marklogic-7

【解决方案1】：

我的理解是，与文件系统相比，有些 XSLT 性能优化很难或不可能在数据库上下文中实现。此外，Saxon 是 XSLT 的行业领导者，并且比市场上几乎任何产品都快得多，尽管这可能无法解释您所描述的巨大差异。

您没有说明您正在运行哪个版本的 MarkLogic，但 8.0 版在 XSLT 性能方面取得了显着改进。我运行的一些简单测试表明速度提高了 3-4 倍，具体取决于 XSLT。

在 Windows 上运行 MarkLogic 时，我遇到了一些罕见但严重的 XSLT 性能边缘案例。 Linux 和 OSX 版本似乎没有这个问题。当 XSLT 任务在多个线程上运行时，它也更加明显。

但是，可以使用xdmp:save 将数据直接保存到文件系统而不是数据库。

除非您的 XSLT 涉及非常复杂的模板规则，否则我建议至少在 XQuery 中测试一些对性能敏感的 XSLT 逻辑。可以移植最慢的部分并将这些查询的结果传递给 XSLT。这并不理想，但您可能能够在不重写 XSLT 的情况下获得可接受的性能。

另一个想法，如果问题只是在多通道 XSLT 中构造变量，则将 XSLT 分解为多个 XSLT，并从 XQuery 对xdmp:xslt-invoke 进行多次调用。但是，我知道拨打xdmp:xslt-invoke 会产生一些开销，因此可能是洗牌，也可能更糟。

【讨论】：

感谢您的快速响应..对不起，我在 Linux 操作系统上运行 Marklogic 7.0-4.1。很高兴知道 8.0 中有一些改进。很遗憾，我无法保存文档，因为 xquery 层使用结果对文档进行进一步处理。
@SalH 虽然这是一项模糊且可能耗时的任务，但我认为您最好的选择是构建一个测试用例并尝试分解 XSLT 逻辑以更好地隔离您的问题并查看是否可以替代处理方式（在较小的 XSLT 部分中，或在一些 XQuery 部分中）执行得更好。此外，有时如果您的任务是在内存中构建非常大的 XML，通常有更好的方法来利用 db.xml。作为最后的手段，您可以将 Saxon 放在网络服务器后面并通过 ML 进行 HTTP 调用。

【解决方案2】：

我在 ML 7 中遇到过与样式表类似的性能问题。想一想，我有与您提到的样式表相似的样式表，即保存节点序列的变量。似乎 xslt 不可能像 xquery 那样优化。如果您对样式表的性能不满意，我建议您将 xslt 转换为等效的 xquery。我这样做并获得了大约 1~1.5 秒的性能提升。这可能是值得的:)

【讨论】：

感谢您的建议。看来这可能是我必须采取的路线。我已经用 ML8 测试了 xslt，但是，我没有看到任何显着的改进，它仍然导致超时。

【解决方案3】：

在我的情况下，似乎在模板匹配规则中使用 fn:not() 函数会导致性能下降。也许如果其他人遇到同样的问题，这可能是一个很好的起点。

【讨论】：

fn:not 不太可能导致您的性能问题，更有可能是其中的表达式。