我们正在使用CruiseControl和StarTeam服务器，并且遇到StarTeam服务器崩溃的问题。我们想知道我们是否太努力了。在3台CruiseControl机器和总共约30个项目中，我们正在登录StarTeam并每隔一分钟检查一次修改。我们的大多数项目都有大约20,000个文件。有没有人对使用StarTeam的此类场景中的性能限制有经验？
我也对CruiseControl与其他版本控制系统（如TFS，Perforce，SVN等）的性能指标感兴趣...当使用CruiseControl和大量包含大量文件的项目时，它们是否存在可伸缩性问题？ ？
答案 0 :(得分：1)
我在使用Star Team进行持续集成方面有一些经验 - 虽然使用TeamCity，而不是使用CruiseControl。在我们的案例中，从TeamCity到StarTeam的常规连接几乎没有注册为我们的性能监控。
您是否查看了服务器上的StarTeam日志文件？ - 通常位于代码库或配置单元的根目录中。我经常发现这些日志足以解决任何问题。
答案 1 :(得分：1)
您希望使用此处所述的“复合修改集”：
StarTeam是否支持“触发器”？您没有让CruiseControl机器每分钟检查一次存储库以进行更改，而是让您的StarTeam计算机让CruiseControl知道何时通过触摸文件更改了代码。
基本上，当对项目进行更新时，VCS会触摸CruiseControl监视的文件（例如project-a-update.txt）。一旦它注意到文件已经更改，CruiseControl就会知道要从VCS进行更新。因此，它每N分钟为每个项目轮询一个文本文件，而不是整个存储库。
答案 2 :(得分：1)
在多个活动项目上运行CC时，我们最大的性能提升是在同一台计算机上安装MPX缓存代理，并确保它存储文件属性和内容。 （好吧，确保在构建中使用ccache。）
StarTeam SDK中存在触发器的概念，但我不确定它与CC的集成程度。要检查是否需要构建，我们将服务器的最后一次拉动保存在一个干净的目录中，并使用stcmd list来比较更改。这非常快。
答案 3 :(得分：0)
据我所知，StarTeam不支持触发器。 CruiseControl.NET StarTeam任务仅支持轮询，我没有看到StarTeam本地支持触发器的任何证据。
尽管将StarTeam推向了极限，但我遇到了同样的问题。我不确定，但我开始认为崩溃问题与同时访问有关，因为当项目由开发人员和CruiseControl高度活跃时，问题会更频繁地发生。
轮询变更的惩罚也变得非常重要。更糟糕的是，罚款加倍。对StarTeam的第一次调用是调用“hist”来获取报告和触发构建的变更集，然后调用“co”对整个源树进行第二次检查并检查任何过时或丢失文件。如果有人可以建议一种方法来创建一个可以消除其中任何一个的StarTeam项目的触发器，我很乐意尝试一下。
答案 4 :(得分：0)
我能找到的另外一些信息。
StarTeam并不总是断开用户（或CruiseControl访问时的代理），并且可能导致同一个用户/代理有数十个打开的连接/登录。不幸的是，很难确定这是否是一个相关问题，因为我无法可靠地使服务器过载。
我们正在使用没有MPX的旧版StarTeam。我想知道是否有人在支持MPX方法的不同持续集成环境中使用StarTeam的经验。
答案 5 :(得分：0)
首先，我没有StarTeam的经验！我确实有过CruiseControl和颠覆的经验。
您可以将计划间隔更改为不那么激进的时间间隔 - 通常可以通过3-5分钟检查项目是否需要构建。但我接受可能有一个原因，你需要经常检查。
Subversion可以很好地扩展。这是因为每当巡航检查是否有更新，它所做的只是将本地版本号与项目的远程版本号进行比较，它不需要检查每个文件。因此，检查的速度不受项目中文件数量的影响。
我希望这会对你有所帮助。