Oracle 具有中央DBMS存储库和版本控制的企业架构师速度非常慢

我们的团队正在使用Sparx的EA，其配置如下：

• EA版本9.3.935
• 使用Oracle数据库的中央DBMS存储库，安装在专用服务器上
• 使用Subversion的版本控制
• 大约30个用户通过局域网连接到一个站点
• WAN优化器尚未使用

SVN的主要用途是作为版本控制和创建基线（如果需要，执行回滚操作）

我们在执行签入和签出操作时遇到问题

将包导出到500 kB的XMI文件时：

• EA中的签出操作耗时16秒
• 在EA中撤消签出花费了46秒（表示完成），但在应用程序准备就绪之前还需要14秒

将包导出到5 MB的XMI文件时：

• EA中的签出操作耗时30秒
• 在EA中撤消签出花费了10分钟+额外的2.5分钟
• 直接通过SVN检查XMI只需1秒

设计规模相当大，而且还在增长

我的问题是：

我们的配置正确吗

如果使用WAN优化器，通常会增加多少性能增益

如何提高这种配置的性能

---

如果需要，我很乐意提供更多信息。谢谢。

这是一个部署问题，因此没有简单、一刀切的解决方案（我就这些问题进行咨询，对于中等规模的组织，通常需要一周或更长的时间），但是：

不，此配置（可能）错误

我不知道WAN优化器在多大程度上提高了版本控制性能

主要的问题是DBMS存储库和版本控制不能很好地混合。对于DBMS，我总是建议只使用基线；外部版本控制（Subversion、TFS等）只应与每个建模器的单独基于文件的项目一起使用。这是因为EA在执行版本控制操作时基本上锁定了整个项目。另一个问题是版本控制包的大小和结构：它们越大，一切都变得越困难

因此，这不是一个解决方案，而是一些提示。还应该注意的是，EA 11（几周前发布）还有另一个部署选项，即“可重用资产服务”，它可能很有用

---

关于所有这些，还有其他问题，例如，请检查。

建议保存小单位的软件包。如果签出分支，则会阻止用户同时处理该分支的子包。此外，划分为小单位会导致更小的XMI，这会导致更快的签入-签出。希望这有帮助。@user3165438:是的，保持包小是一个想法，但要控制的包的级别与另一个不同，这意味着要标准化包的控制版本，例如级别3（树的深度）上的所有包。但是从版本控制最佳实践文档中可以看到最佳实践1：在一个集中的团队模型中，将版本控制应用于模型层次结构中的所有包，包括子包和根节点，以最大限度地提高并行工作的可能性。所以我想，这应该不是一个问题。是的，当您不锁定（签出）分支层次结构中的第一个包时，会启用并行工作。谢谢Uffe，我也看到了这个问题。1.是否有任何仅与DBMS一起使用基线的参考？2.是的，保持包小是一个想法，但是要控制的包的级别变得不一样了好的，我发现了没有版本控制的管理基线。这也是将所有包（嵌套）保持在版本控制中的最佳做法。@David，很想知道您是如何设法提高EA-SVN性能的。@user3165438:目前通过在最小的版本中执行签入/签出操作package@David. 你在这里发表的关于这个主题的文章似乎非常有用。谢谢