|
•
|
The AccuRev Server software runs on one machine, as a multi-threaded operating system process, named accurev_server. The Server manages the AccuRev repository, where all data under AccuRev management is stored.
|
|
•
|
AccuRev Client software runs on each AccuRev user’s machine. The command-line interface is implemented as a single program, accurev, which executes a single command and then exits. The graphical user interface is implemented as two programs: the user-visible Java application acgui is long-lived; when the user invokes a command through the GUI, acgui runs the background application accurevw, which communicates with the Server and then exits.
|
As the above description indicates, the AccuRev Server is the heart of the AccuRev system. The sizing and configuration of the AccuRev Server machine significantly impacts the performance perceived by users. We highly recommend that you first read The AccuRev Data Repository of the AccuRev Concepts Manual, along with the rest of this manual. We also recommend that you attend training courses offered by AccuRev, Inc.
This diagram illustrates the AccuRev “performance stack”. The highlighted components are the ones that are under customer control — each component can influence the user’s experience of AccuRev either positively or negatively. In particular, a problem at any level can severely degrade the user’s experience of AccuRev performance. We strongly recommend that a top-to-bottom assessment of all of these components be performed prior to deploying AccuRev on the enterprise level.The AccuRev Server is a multi-threaded application. Each individual AccuRev operation, such as executing a History command, uses only one thread, which runs on one CPU. When multiple client command requests arrive at the AccuRev Server at (approximately) the same time, these commands are executed through normal operating system multitasking. On a multiple-CPU machine, the threads are shared across all available CPUs.
Experience indicates that, on average, a user will actually “hit” the AccuRev Server for less than 5 minutes per day. Typically, Server utilization is not uniform throughout the day, but tends to form peaks and valleys. For example, you might find that multiple users Keep their changes just before the nightly build is started, or that users tend to Update their workspaces at approximately the same time (e.g. when they arrive at work, or just after lunch).
Customer data has consistently shown that “peak load” rarely exceeds 15%. That is, you are unlikely to experience a situation in which more than 15% of the active AccuRev users have overlapping requests being processed by the AccuRev Server. (You can determine the number of active users by examining the Server log. Or you can simply assume that all the users listed by the command accurev show users are active.) The most common command request during peak load periods is Update. This also is the AccuRev command that requires that most processor, disk, and network resources.
AccuRev’s network bandwidth usage is similar to that of ftp. For instance, a keep command on 100 files needs to send a list of 100 files to the server, in addition to the contents of those files. AccuRev is transaction-based; it often works on groups of files in a single transaction. Thus, the full list of file names and contents is sent to the server in one burst. This minimizes changes in the direction of data transfer, effectively removing the impact of any network latency.