在 Lucee 中查找 XSLT 性能不佳的原因答案

【问题标题】：Finding the cause for bad XSLT performance in Lucee在 Lucee 中查找 XSLT 性能不佳的原因
【发布时间】：2017-03-24 21:15:19
【问题描述】：

我们正在努力寻找 XSL 转换在相当长一段时间内偶尔表现不佳的原因。

到目前为止，我们还无法确定真正的原因，因为它可能在高负载下发生，也可能在服务器基本上空闲时发生。所附示例发生在 15 分钟内有 158 个请求时。因此，根本没有可提及的负载。

我们怀疑在转换中使用了一些外部 XML 文档，但这似乎也不是问题，因为它们通常在几毫秒内加载，有时可能是几秒钟，但没有什么可以解释 200 多秒的已收到请求。

当我们稍后尝试它们以检查是否存在问题时，相同的转换运行得很好。

我们正在运行 Fusion Reactor 来监控我们的服务器，但也没有什么异常可看的。在昨天的案例中，既没有高 CPU 负载，也没有其他异常情况。

我附上了一张来自 Fusion Reactor 分析器的屏幕截图，您可以在其中看到所用的时间，如果我们正确解释结果，它似乎总是占用 99.x% 时间的“scanDocument”部分。

有什么方法可以找出造成延迟的原因吗？

我们当前运行的版本是：

Ubuntu：14.04.5 LTS 爪哇：1.8.0_45 Lucee：4.5.4.017 决赛

【问题讨论】：

【解决方案1】：

好吧，SocketInputStream.sockerRead0 中有 99.8%，所以我会责怪网络连接速度慢。

程序的其余部分只是等待字节通过慢速网络连接到达，所以你看不到高 CPU

【讨论】：

嗯，这听起来像是我们最初的怀疑，但在那个时候我们看不到任何缓慢的传出请求。我们将 squid 作为记录所有非 https 请求的代理运行，并且所讨论的转换不包含任何我们看不到的 https 文档。这也可能是 Lucee 或 Java 内部的一些内部通信问题吗？
@korguell：为什么不对所有需要的 XML 和 XSLT 文件的本地副本进行实验？
@korguell 我怀疑输入流的速度很慢，也许您可以运行 wireshark 或一些 UL/DL 速度计工具来监控您的网络连接？
此类问题通常是由从 W3C 站点获取知名 DTD 或模式的请求引起的。 W3C 故意限制这些请求以阻止这种做法。