Hi folks,
As you may have noticed, Google Code's Subversion service is still
pretty slow... still much slower than a stock Subversion/Apache server
running on a single box. It turns out to be tricky to work with
bigtable: you get massive scalability, but in return you have to
convert all of BDB's disk i/o calls into network RPCs. On a single
box, the disk i/o calls get faster over time as the OS eventually ends
up swapping the underlying filesystem into memory. But network RPCs
are slow and stay slow. :-/
If you haven't yet heard the rumors, it's true: Jon Trowbridge is now
working on re-optimizing our libsvn_fs_bigtable library to be much
faster. This not only means some major bigtable schema changes, but
evolving our filesystem implementation to no longer be just a simple
fork of libsvn_fs_base. We're making some really huge changes to our
implementation, and Jon has started encountering quite a number of
problems in Subversion's core code and design. When I say "problems",
what I really mean is "lots of hidden assumptions" about things that
somebody doing a clean-room implementation of svn_fs.h would run into.
Some of these things are simply brittle tests or poor documentation
in svn_fs.h, but others seems to be some actual bugs that we've been
lucky to avoid just because libsvn_fs_{base|fs} just happen to do
things a certain way!
In any case, I've asked Jon to start posting to this list when he
encounters such things, and I wanted to give people some context for
his postings.
Honestly, I'm pretty excited by this feedback. It's rare when we get
such an incredibly fresh set of eyes on our code! We strive to make
our docs and APIs as open as possible, so I'm really keen on hearing
when they're not working correctly for newcomers.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2364646
Received on 2009-06-23 21:28:44 CEST