Smart server plans for 1.7: effort tests, single RPC for branch opening, server-side autopacking.

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Bennetts wrote:
| Now that 1.6 is finally close, I've been looking ahead a little to
what I plan
| to do for 1.7.  I'll be taking a two week break during the 1.7 cycle
so I don't
| want to bite off *too* much though.
|
| The key thing for smart server network performance is still reducing round
| trips.  For instance, many of the problems identified at
| <http://bazaar-vcs.org/SmartPushAnalysis1.4> are still problems.  So
I'm going
| to write (and document how to write!) some of what Martin calls
“effort” tests:
| tests that assert that only a fixed (or at least deterministic) amount
of effort
| is expended to do an operation.  For the smart server code, this
basically means
| counting the remote calls (i.e. round trips) that a client makes.
| test_remote.py already tests this to some extent on a method-by-method
basis,
| but I want to get to the point where we can say that e.g. pushing a
branch does
| N calls, and have a test fail if something accidentally adds more calls.
|
| In case that sounds a bit abstract, here's an example: currently
performance
| bugs like locking, unlocking and then relocking a branch during a
single push
| aren't noticed by the test suite.  This should help catch this sort of
problem.
| In fact, a test that simply tracks lock/unlock calls rather all calls
might be a
| productive starting point...
|
| That's not the only thing I want to do for 1.7.  In terms of concrete
| improvements, I want to do a few things that I think are fairly cheap
to fix,
| but will help smart protocol performance:
|
|  * using a single RPC to open branches (including the repo and
bzrdirs).  This
|    will help basically every single smart operation.
|  * server-side autopacking.  I previously sent a hackish (and buggy)
patch as an
|    RFC; I think it shouldn't be too hard to polish this.  It's an interim
|    solution (long term a single “Repository.insert_revisions” verb
would be
|    better than manipulating pack files directly), but it's a cheap
improvement.
|
| -Andrew.
|

I like both of these a lot. As you say, relatively cheap to do, and have
potentially large impact. (At least on the "bzr up" with nothing to do,
we can figure that out in 1-ish round trip, instead of 15.)

As for "effort" tests. I would really like something like this, and sort
of wish we could do memory-related ones.

I was actually thinking we could do a memory bound test now that we have
"bzr -Dmemory". My idea would be to create a say 50MB file, and then
commit it, and ensure that memory doesn't go about 200MB (or whatever is
reasonable.) And then ratchet down that upper limit as we get rid of
extra copies. The idea is to use a number large enough that copying the
text will show up in memory, but is immune to the little allocations for
everything else we might do.

Or say, hardlink 10 of these files, etc. I wouldn't want to be abusive
on disk space for the test, but I think we could really use some amount
of memory consumption testing.

Any thoughts on how to do it tastefully?

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiZofwACgkQJdeBCYSNAAMFOACgpX/54nk0j0HSjORSa+dqRXWg
QGcAnRMJZmHUqLWr+H7CYlAuQS3Dtlvp
=ktb8
-----END PGP SIGNATURE-----