GitCentric Multi-Threaded Bridge

Provides performance, limitations and configuration information for the multi-threaded bridge.

In this topic:

Performance impact single operation

Sync operations are timed one-at-a-time with the old single-threaded bridge and the new multi-threaded bridge. The timings were within one second with the two different bridges. Performance Impact Multi-threaded operations The framework was tested with five threads simultaneously causing sync operations and timed those sync operations.

With the multi-threaded bridge the sync operations were 50% slower than one-at-a-time operations. Expect some slowdown because the bridge, AccuRev Server, and Gerrit server will be busier. With the single-threaded bridge the five thread test sync operations were about three times slower than one-at-a-time sync operations. They were not five times slower because some of the activity in the Gerrit server and the AccuRev Server is already multi-threaded.

The main realized objective is that push operations not be blocked for the duration of a long running operation.

Back to top

Limitation: Operations within a repo are still serialized

Synchronizations are run in parallel now except for synchronizations on the same repository. To avoid race conditions that are repository specific data structures, those operations are serialized. This means that if a long running operation start on one branch of a repository (for example, and initial synchronization with a stream that has 20,000 files) and a push occurs on a second mapped branch in that same repository, that push will still block until the long running operation completes.

Back to top

Configuration

To achieve best performance from GitCentric, correct configuration is necessary. For this test, modify the

<install>/site/etc/gerrit.config file's sshd section as follows:

[sshd]
 listenAddress = *:29418
 threads = 48
 batchThreads = 2 
 streamThreads = 50
 maxAuthTries = 12

Increasing the number of threads might further improve GitCentric performance, if the server has sufficient cores.

We also modified the tomcat environment script in <accurev install>/WebUI/tomcat/bin/setenv.sh script to the following:

export CATALINA_OPTS="$CATALINA_OPTS -server -Xms256m -Xmx1024m"

Note that -Xmx1024m implies a maximum heap size 1024MB. Given available memory, a larger heap will further improve performance.

Back to top