Coldfusion 似乎赶上了加载 UDF答案

【问题标题】：Coldfusion seems to get caught up loading UDF'sColdfusion 似乎赶上了加载 UDF
【发布时间】：2010-10-05 20:51:30
【问题描述】：

我目前在服务器上运行的站点太多，我认为模板缓存无法处理它。但是，最大的拖累似乎是当我为每个站点加载我的 UDF 库时。我这样说是因为每当我运行 Fusion Reactor 来查看阻塞在哪里时，堆栈跟踪总是位于加载 UDF 的模板上。

这是解决更多 RAM 和更高模板缓存的唯一方法，还是有更好的方法？

也许我也错了，还有别的问题吗？

【问题讨论】：

请告知您的服务器配置和您拥有的站点数量（假设“太多”太不确定了）。
大约 55 个站点和 44,486 个模板（假设其中超过 60% 是不包括在全部站点中的废旧站点）每个站点本身都有大约 500 个模板。服务器是 P4 3Ghz，2gb RAM，2048 模板缓存，1024mb Min/Max JVM Heap Size。我知道服务器严重不足，并且正在迁移到更好的环境，但就像我说的，任何时候出现问题似乎总是在加载 UDF 期间，所以我想确保之前我迁移了，我可以先弄清楚我在做什么=]

【解决方案1】：

在增加可用的堆和模板缓存之前，先看几件事。

首先，系统中的模板实际上是否比模板缓存多？如果没有，增加它肯定无济于事。即使你这样做了，如果他们不经常被调用，它可能也无济于事，但这更难衡量。

其次，检查服务器是否在实际加载 UDF 时遇到困难，或者页面是否在执行 UDF 时遇到问题。函数是否包含在调用它们的同一模板中？

第三，找出为什么加载这个 UDF 库需要这么长时间。真的有那么大吗？可以拆分成更小的库吗？是否有一个（或多个）特定的 UDF 似乎会挂起编译过程？

最后，如果每个请求都必须加载一个大型 UDF 库，我会考虑使用 Application 范围来存储它。包含库 onApplicationStart()，然后将函数引用为 application.myFunction()。这可以防止 CF 在每次请求时都需要加载（并可能编译）文件。

【讨论】：

是的，服务器上的模板太多了。并非所有这些都经常受到打击，但根据我的理解/堆栈跟踪，每次请求挂起时都是在文件写入操作期间，同时点击加载 udf 文件的模板。该库包含大约 8 个文件，因此数量不多（但有 20 多个站点）。我主要是推测coldfusion在编译包含UDF的模板时必须做额外的提升。 UDF 都是前端加载的。将它们移动到应用程序听起来不会改变模板缓存的任何内容。
实际上，将它们移动到应用程序范围意味着它们在应用程序初始化时被加载一次，这意味着模板可以从模板缓存中转储，因为它们永远不会重新编译和加载。它们仅在应用程序重新启动时重新加载。但是，您说它在文件写入时死了-可能是驱动器故障吗？还是磁盘空间不足？还是需要碎片整理？
10/70 GB 免费，42% 碎片，84% 文件碎片。哇，这太可怕了。自从我担心碎片化以来已经有一段时间了。可能就是这样。
顺便说一下，我今晚安排了碎片整理，所以希望明天我能告诉你是否是这种情况。
好吧，碎片整理有点工作，但我不知道它是否有帮助。碎片整理并没有得到所有碎片，但肯定更少。我将不得不密切关注服务器。我也申请了这个kb2.adobe.com/cps/865/cpsid_86589.html 看看它是否有帮助。