【发布时间】：2016-01-21 20:54:30
【问题描述】：
我们在使用 Alfresco 4.0.e 和 mysql 5.5 后端时遇到了一些性能问题。
通过性能监视器，我可以看到很多请求（不知道是什么触发了这些请求）挂在 DB 上，响应时间接近 100-200 秒。在极端情况下为 3000 秒。
所有这些请求都来自 alfresco 应用程序（不是我们在单独服务器上的共享 gui）。客户端 ip 显示 127.0.0.1。 URL = /alfresco/service/api/solr/metadata 在进一步深入研究时，似乎有 2 个查询需要超过 100 秒，每个查询如下所示-
select
assoc.id as id,
parentNode.id as parentNodeId,
parentNode.version as parentNodeVersion,
parentStore.protocol as parentNodeProtocol,
parentStore.identifier as parentNodeIdentifier,
parentNode.uuid as parentNodeUuid,
childNode.id as childNodeId,
childNode.version as childNodeVersion,
childStore.protocol as childNodeProtocol,
childStore.identifier as childNodeIdentifier,
childNode.uuid as childNodeUuid,
assoc.type_qname_id as type_qname_id,
assoc.child_node_name_crc as child_node_name_crc,
assoc.child_node_name as child_node_name,
assoc.qname_ns_id as qname_ns_id,
assoc.qname_localname as qname_localname,
assoc.is_primary as is_primary,
assoc.assoc_index as assoc_index
from
alf_child_assoc assoc
join alf_node parentNode on (parentNode.id = assoc.parent_node_id)
join alf_store parentStore on (parentStore.id = parentNode.store_id)
join alf_node childNode on (childNode.id = assoc.child_node_id)
join alf_store childStore on (childStore.id = childNode.store_id)
where
parentNode.id = ?
在这个查询上运行一个解释计划，参数值似乎造成了最大的破坏（~3000 秒），这就是我所看到的-
select_type table type possible_keys key key_len ref rows Extra
SIMPLE parentNode const PRIMARY,store_id,fk_alf_node_store PRIMARY 8 const 1
SIMPLE parentStore const PRIMARY PRIMARY 8 const 1
SIMPLE childStore index PRIMARY protocol 454 NULL 6 Using index
SIMPLE childNode ref PRIMARY,store_id,fk_alf_node_store store_id 8 alfrescomgr.childStore.id 162579
SIMPLE assoc ref parent_node_id,fk_alf_cass_pnode, fk_alf_cass_cnode 8 alfrescomgr.childNode.id 1 Using where
fk_alf_cass_cnode
注意行数 = 162k。 对于几个这样的查询，父节点似乎指向一个存储数千个小型报价文档的文件夹。
我们的应用程序推送文档并通过一些元数据属性（例如客户 ID）来查询它们。我们使用 apache chemistry cmis api 进行交互。
- 您认为是什么触发了 solr 查询。它试图在所有子节点上加载信息。
- 如果我们无法控制 solr 部分，我们该如何优化它。
非常感谢您的帮助。
【问题讨论】：
-
一般不建议在 Alfresco 中将数千个文件放在一个文件夹中。如果您将文件分片到子目录中，每个分片文件夹中只有几百个，会发生什么情况？
-
另外，现在有点晚了，但 PostGreSQL 通常比 MySQL 好很多！
-
感谢您的意见。子目录是我们正在考虑的事情，但需要找到一种方法能够将这些文件移动到适当的文件夹中，而不会在生产中造成性能噩梦。我想知道 Aurora 会如何工作，尤其是看着 Alfresco perf。他们在 aws 论文中发布的基准。我想知道社区版本是否可以与 Aurora 一起使用。
-
如果您从 4.0 升级到 5.0（甚至可能是 5.1 预览版），您将获得相当多的性能改进，而无需移动任何东西。自从 4.0 大约 4 年前问世以来，已经完成了很多工作！