monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Some numbers for push/pull to/from a memory database


From: Thomas Keller
Subject: [Monotone-devel] Some numbers for push/pull to/from a memory database
Date: Tue, 01 Sep 2009 00:24:41 +0200
User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812)

Hi folks!

After Timothy enabled the ability to sync and serve sqlite memory
databases I thought I should take a quick look if this improves anything
on either push or pull in contrast to a regular file-based database.

I used revision 76491f465ab5461f99fa01ef0a4122ff2ca21eb9 for my tests.

These are the numbers, the first number is the total time measured on my
Core 2 Duo 2.16 GHz, the second in brackets the user time:



           Parall. - Mem  Single - Mem  Parall. - Disk  Single - Disk
push
  mtn-viz  24.4 ( 7.0)    11.8 ( 6.8)   24.9 ( 7.0)     12.1 ( 6.8)
  guitone  42.5 ( 9.6)    34.6 ( 9.4)   44.7 ( 9.6)     36.6 ( 9.5)
pull
  mtn-viz  20.3 ( 5.6)     8.6 ( 5.5)   18.5 ( 5.6)      8.6 ( 5.4)
  guitone  45.3 (28.7)    39.7 (28.7)   45.2 (28.8)     39.6 (28.7)

mtn-viz: net.venge.monotone-viz, 351 Revisions, 1.3 MB
guitone: net.venge.monotone.guitone, 961 Revisions, 4.7 MB



I've tested pushing both branches from a file-based client to a
memory-based and a file-based server, once one project after another
(single) and once both processes in parallel. Then I did the same for
pull, again. (I figured it does not make much sense for a client to have
a memory-only database so I skipped that :)

One thing what I see here is a small speed improvement in the overall
time when pushing to a memory-based server. For a push with 1000
revisions this saves us about two real seconds. However, I also saw a
huge speed penalty when both processes ran in parallel - while both
tickers suggested that the process should be finished, they stalled
shortly after the single shot's time and took the rest of the time
sitting there doing nothing. Is there an explanation for this behaviour?

While push gained some speed, pull did not and even took a little longer
here and there. I have to note here that all three processes of course
used the same hardware, so there could be a speed penalty because of
this, but since each pull method (db vs memory-based server) suffers
from the same, the CPU should be actually irrelevant in this comparison.

What I have not expected is this very high user time for pulling
nvm.guitone, so lots of work seems to be done in the client here. I
haven't tuned forward / backward delta usage with the server
configuration, maybe this would have helped a little bit here.

It would be interesting to see how a memory-based server behaves with
more than my simulated two clients in parallel, maybe it gets faster
then than the file-based one. In the end I thought it would get already
faster with smaller numbers of revisions and clients, but it didn't.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]