Martin Geisler avatar Martin Geisler committed a04358b

Test results

Comments (0)

Files changed (11)

Add a comment to this file

results/hg-pull-response-times-intervals.png

Added
New image
Add a comment to this file

results/hg-pull-response-times.png

Added
New image
Add a comment to this file

results/hg-push-empty-response-times-intervals.png

Added
New image
Add a comment to this file

results/hg-push-empty-response-times.png

Added
New image
Add a comment to this file

results/hg-push-force-response-times-intervals.png

Added
New image
Add a comment to this file

results/hg-push-force-response-times.png

Added
New image
Add a comment to this file

results/idle-time-response-times-intervals.png

Added
New image
Add a comment to this file

results/idle-time-response-times.png

Added
New image
Add a comment to this file

results/wait-time-response-times-intervals.png

Added
New image
Add a comment to this file

results/wait-time-response-times.png

Added
New image
 
 The test was made using two machines in a LAN. Both machines had 2.8
 GHz Intel Core i7 CPUs, the RhodeCode server had 4 GiB of RAM and the
-client had 6 GiB.
+client had 6 GiB. The server is using the built-in Pylons webserver
+and a SQLite database.
+
+In the tests, a varying number of worker threads were running in a
+loop, repeatedly doing:
+
+1. ``hg pull`` to get the latest changes.
+2. Merge all heads.
+3. Make two commits, each consisting of two random edits to three
+   random files.
+4. ``hg push -f`` to unconditionally push the new changesets.
+5. ``hg push`` to check pushing when there is nothing to push.
+
+Results
+-------
+
+The graphs below show the results when up to 48 threads were working
+in parallel on eight test repositories. The repositories were clones
+of the Mercurial repository itself. One thread was started every 10
+seconds for the first 480 seconds. The 48 threads were then left
+running for 120 seconds more, for a total test time of 10 minutes.
+
+This is the results for the different operations are below. The raw
+response times are plotted first, then comes a plot showing the
+average time, and the 80- and 90-percentile times based on 30-second
+intervals:
+
+* ``hg pull``:
+
+  .. image:: results/hg-pull-response-times.png
+  .. image:: results/hg-pull-response-times-intervals.png
+
+* ``hg push -f``:
+
+  .. image:: results/hg-push-force-response-times.png
+  .. image:: results/hg-push-force-response-times-intervals.png
+
+* ``hg push``:
+
+  .. image:: results/hg-push-empty-response-times.png
+  .. image:: results/hg-push-empty-response-times-intervals.png
+
+We see, that the response time grows more or less linearly with the
+number of simultaneous clients. Even with 48 clients all pushing and
+pulling data at the same time, ``hg pull`` (a lock-less operation)
+will normally complete in less than 30 seconds, and ``hg push`` takes
+less than 50 seconds when there's data to push.
 
 
 Warnings and Errors
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.