1

我正在帮助安装 Drupal 6 的人，他们对网站的性能感到非常苦恼，即使他们只处于定义内容类型的阶段。仅加载模块列表可能需要 30 多秒，导入内容类型需要近 3 分钟。

它安装在一个大型共享 UNIX 系统上，我在同一台服务器上运行其他 D6 安装，没有真正的问题（有些慢，但没有这么糟糕）。今天下午我花了一些时间禁用站点上的所有非核心模块，并且能够将模块列表页面的加载时间缩短到大约 5 秒。当我重新启用模块组时，似乎对性能造成最大影响的是 CCK 系列模块（模块列表的页面加载时间增加了 15-20 秒）。

同样，我在此服务器上还有其他站点也在运行 CCK（以及大多数相同的其他模块）并且没有遇到类似的事情。主要区别在于，这个非常慢的站点定义了大量的内容类型和 CCK 字段——46 个独立的内容类型和 162 个 CCK 字段。

我得出的结论是，网站性能（至少在某些与创建和编辑内容类型有关的操作中）与内容类型和自定义字段的数量之间存在直接联系，但我无法确定到底是什么此内容类型和字段的影响是什么，以及您是否可以采取任何措施来减轻它们的影响。

我确实安装了开发模块，发现模块页面上最大的性能消耗是与 cache_menu 相关的查询，但我不确定这是否与内容类型和/或字段的数量直接相关。

任何指导表示赞赏！

谢谢，保罗

4

2 回答 2

1

首先：模块页面确实是一个邪恶的野兽，因为它完全刷新了 Drupal 的所有内部缓存并重建它们以确保新安装的模块具有最新数据。它不是一个很好的站点性能预测指标（因为通常只有特定的管理任务会刷新这些类型的缓存），尽管它很烦人。

第二：导入内容类型也会刷新这些缓存，因为 CCK 想要确保一切都是最新的。这是次优的，但你有它。

最后：您拥有的 CCK 字段和内容类型的数量确实会影响刷新和重建缓存时完成的工作量。CCK 提取有关所有已定义内容类型及其字段的所有信息，构建一个数据结构来描述它们，并使用该缓存版本供以后参考。由于有数百个字段和数十种内容类型，重建数据缓存需要更长的时间，从而加剧您在模块页面和导入新内容类型时看到的延迟。

好消息（例如）是这个特定问题对站点的整体性能没有太大影响，只是刷新这些缓存的管理操作。

于 2009-08-05T21:29:13.923 回答
0

这与我对另一个 Drupal 问题的回答相同；如果伊顿的回答没有解决您的问题，也许您应该看看 Views 模块和动态菜单重建。每次，菜单都会被重建，导致 100 甚至 1000 的查询。根据连接的创建方式，您最终可能会在同一个表上得到两个相似的连接，从而导致查询数量增加一倍。更多信息可以在这里找到

于 2009-08-11T19:24:51.253 回答