Accurev 性能如何？
Accurev 当前版本 (4.7) 的性能如何？
- 每 100mb、每 GB 的结账时间？
- 每 # 个文件或 mb 的提交时间？
- 当 100+ 流时 gui 的响应能力？
我刚刚进行了 Accurev 的演示，这些流看起来像是一种围绕代码/项目建模工作流程的轻量级方法。我听到人们称赞 Accurev 的流后端并抱怨其性能。 Accurev 似乎对性能进行了研究，但我想获得一些真实世界的数据，以确保这不是演示-运行良好-运行较差的情况。
有人有 Accurev 性能轶事或（甚至更好）测试数据吗？
How is performance in the current version (4.7) of Accurev?
- time to checkout per 100mb, per gb?
- time to commit per # of files or mb?
- responsiveness of gui when 100+ streams?
I just had a demo of Accurev, and the streams look like a lightweight way to model workflow around code/projects. I've heard people praising Accurev for the streams back end and complaining about performance. Accurev appears to have worked on the performance, but I'd like to get some real world data to make sure it isn't a case of demos-well-runs-less-well.
Does anyone have Accurev performance anecdotes or (even better) data from testing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我没有任何数字，但我可以告诉您我们在哪里注意到了性能问题。
我们的构建通常使用源代码管理中的 30-40K 文件。目前，我的工作区中有超过 66K 个文件，包括构建中间文件和输出文件，大小超过 15GB。为了使 AccuRev 能够响应地工作，我们积极使用忽略元素，以便 AccuRev 忽略任何中间文件，例如 *.obj。此外，我们还使用时间戳优化。一般来说，运行更新很快，但项目规模通常为 5-10 人，因此如果每天更新，通常只会删除几十个文件。即使有人进行了涉及大量文件的更改，速度也不是问题。另一方面，完全填充所有 30K+ 文件的速度很慢。我没有时间，因为我很少这样做，而且在极少数情况下，我会在去吃午餐或开会时运行填充。我预计最多可能需要 10 分钟。一般来说，源文件下载得很快，但我们有一些大的二进制文件，10-20MB，每个文件需要几秒钟。
如果排除规则和忽略元素配置不正确，AccuRev 可能需要几分钟的时间来运行此大小的工作区的更新。当我听到其他开发人员抱怨速度时，我知道有些东西配置错误，我们会解决它。
大约一年前，其中一个项目更新了 boost 超过 25K 个文件，并将 FireFox 添加到存储库中（忘记了大小，但使 boost 看起来很小）。他们还添加了 ICU，编写了大量软件并修改了无数文件。我记得流中大约有超过 250K 个文件。不幸的是，我决定将他们所有的好代码都提升到根目录，以便所有项目都可以共享。事实证明，这有点超出了 AccuRev 的处理能力。推动所有变更是一个持续数小时的过程。我记得 FireFox 推广后，其余的一切都很顺利 - 也许是一个包含超过 100K 个文件的事务是问题所在？
我最近更新了 boost，因此必须保留并升级 25K 以上的文件。这花了一两分钟，但考虑到文件的数量和二进制文件的大小，这并不是不合理的。
至于流的数量，我们有超过 800 个流和工作区。这里的性能不是问题。一般来说，我发现大量的流很难导航，因此我仅运行我的工作区和我感兴趣的流的过滤视图。但是，当我需要查看未过滤的列表以查找某些内容时，性能很好。
最后一点，AccuRev 支持非常棒 - 我们称它们为天空中的声音。我们时常使用 AccuRev 搬起石头砸自己的脚，最终却对如何解决问题一无所知。我们几乎总是做了一些愚蠢的事情，然后尝试一些更愚蠢的事情来解决它。最终我们提出了支持请求，接下来我们知道他们通过电话或转到会议引导我们完成正义的步骤。我什至因为一些琐碎的事情联系过他们，因为我忙了一天，所以我没有时间去解决这些问题，他们很友善地引导我完成这些事情，而不是告诉我 RTFM。
I don't have any numbers but I can tell you where we have noticed performance issues.
Our builds typically use 30-40K files from source control. In my workspace currently there are over 66K files including build intermediate and output files, over 15GB in size. To keep AccuRev working responsively we aggressively use the ignore elements so AccuRev ignores any intermediate files such as *.obj. In addition we use the time stamp optimization. In general running an update is quick, but the project sizes are typically 5-10 people so normally only a couple of dozen files come down if you update daily. Even if someone made changes that touched lots of files speed is not an issue. On the other hand a full populate of all 30K+ files is slow. I don't have a time since I seldom do this and on the rare occasion I do, I run the populate when I'm going to lunch or a meeting. I expect it could be as much as 10 minutes. In general source files come down very quickly, but we have some large binary files, 10-20MB, that take a couple of seconds each.
If the exclude rules and ignore elements are not correctly configured, AccuRev can take a couple of minutes to run an update for workspaces of this size. When I hear of other developers complaining about the speed I know something is miss-configured and we get it straightened out.
A year or so ago one of the project updated boost with 25K+ files and also added FireFox to the repository (forget the size but made boost look small.) They also added ICU, wrote a lot of software and modified countless files. In all I recall there were approx 250K+ files sitting in a stream. I unfortunately decided that all their good code should be promoted to the root so all projects could share. This turned out to be a little beyond what AccuRev could handle well. It was a multi hour process getting all the changes promoted. As I recall once FireFox was promoted the rest went smoothly - perhaps a single transaction with over 100K files was the issue?
I recently updated boost and so had to keep and promote 25K+ files. It took a minute or two but not unreasonable considering the number of files and the size of the binaries.
As for the number of streams, we have over 800 streams and workspaces. Performance here is not an issue. In general I find the large number of streams hard to navigate so I run a filtered view of just my workspaces and the just streams I'm interested in. However when I need to look at the unfiltered list to find something performance is fine.
As a final note, AccuRev support is terrific - we call them the voice in the sky. Every now and again we shoot ourselves in the foot using AccuRev and wind up clueless on how to fix things. Almost always we did something dumb and then tried something dumber to fix it. Eventually we place a support request and next thing we know they are walking us through the steps to righteousness either on the phone or a goto meeting. I've even contacted them for trivial things that I just don't have time to figure out as I'm having a hectic day and they kindly walk me through it rather than telling me to RTFM.
2014 年编辑：我们现在可以通过使用 RealVNC 的商业版本获得可接受的 X-Windows 性能。
原文评论：这个答案适用于Accurev的任何版本，而不仅仅是4.7。首先，如果您可以使用 Web 客户端，GUI 性能可能还不错。如果您无法使用 Web 客户端并且想要 GUI 性能，那么您最好使用 Windows，或者将所有开发人员集中在一处，即 Accurev 服务器所在的位置。尝试通过 WAN 在 X-Windows 上运行 GUI 吗？算了：我们的经验是基本的点击操作需要几十秒或几分钟。这是通过大约 800 英里远的相当良好的 WAN 进行的，具有几乎最佳的 ping 时间。这不是 Accurev 的故障，而是 X-Windows 的故障，并且您可能会在 WAN 上使用其他 X 应用程序时遇到类似的问题。因此，如果可能的话，请避免使用基本的 X。目前我们不能，并且我们的 WAN 用户被强制降级为只能使用命令行。基本问题是 Accurev 是中心化的，你无法提高光速。我相信您可以通过运行 Accurev 复制服务器来解决 WAN 延迟问题，但如果您通过 VPN 在单人办公室有远程开发人员，那么这仍然无法正确解决问题。具有讽刺意味的是，复制服务器在某种程度上将这种集中式 VCS 转变为 DVCS 的一种形式。如果您没有复制服务器，那么一个可怕但有些可行的解决方法是使用增量同步工具（例如 rsync）在可以运行 GUI 的本地计算机（即直接在您的计算机上运行的 GUI）之间同步源树。 Windows 或 Linux 笔记本电脑），以及您实际工作的机器（例如 1,000 英里外的 UNIX 机器）。另一种选择是使用 VNC 之类的东西，它在 WAN 上比 X 工作得更好，连接到 Accurev 服务器位置的虚拟桌面，然后从那里使用 X。在我的工作场所，不止一个团队会同时使用 Mercurial，并仅在绝对必要时才升级为 Accurev。正如 Stephen Nutt 上面指出的，其他必要的工作是使用时间戳优化并忽略。当我们需要包含大量文件时，我们的 Accurev 管理员（是的，它需要你雇人来照顾它）也会抱怨，尽管事实上它们构成了我们产品的核心部分，并且必须包含在内并进行版本控制。得出你自己的结论。
Edit 2014: We can now get acceptable X-Windows performance by using the commercial version of RealVNC.
Original comment:This answer applies to any version of Accurev, not just 4.7. Firstly, GUI performance might be OK if you can use the web client. If you can't use the web client and if you want GUI performance then you'd better be using Windows, or have all your developers in one place, i.e. where the Accurev server is located. Try to run the GUI on X-Windows over a WAN ? Forget it : our experience has been dozens of seconds or minutes for basic point and click operations. This is over a fairly good WAN about 800 miles distant, with an almost optimal ping time. This is not a failing of Accurev, but of X-Windows, and you'll likely have similar problems with other X applications over a WAN. So avoid basic X if you possibly can. Currently we cannot, and our WAN users are forcibly relegated to command-line only. The basic problem is that Accurev is is centralized and you can't increase the speed of light. I believe you can get around WAN latency by running Accurev Replication Servers, but that still does not properly address the problem if you have remote developers at single-person offices over VPN. It is ironic that the replication servers somewhat turn this centralized VCS into a form of DVCS. If you don't have replication servers then a horrible but somewhat workable work-around is to use a delta-synchronization tool such as rsync to sync your source tree between your local machine where you can run the GUI (i.e. GUI running directly on your Windows or Linux laptop), and the machine where you're actually working (e.g. UNIX machine 1,000 miles away). Another option is to use something like VNC which works better over a WAN than X, connecting to a virtual desktop at the Accurev server's location, and use X from there. At my workplace more than one team has resorted to using Mercurial on the side and promoting to Accurev only when it's strictly necessary. As Stephen Nutt points out above, other necessary work is to use time-stamp optimization and ignores. We also have our Accurev admins (yes, it requires you employ people to baby sit it) complain when we need to include large numbers of files, despite the fact they form a core part of our product and MUST be included and version controlled. Draw your own conclusions.