On 07/03/2010 03:28 PM, Stefan Fuhrmann wrote:
> Go and grab your share at
> It is SVN 1.7 + APR 1.3 + ZLIB 1.2.5 tuned for svnadmin and
> threaded svnserve performance with FSFS. All tests pass on Linux.
> -- Stefan^2.
> What is this all about?
> A couple of weeks ago, I started working on SVN's server performance.
> Without access to a development repository, I found it hard to
> develop a compelling solution to the underlying problems. Thus,
> the baby-step patches I sent to this and other lists got often
> So, I decided to set up a project in my own repository and to
> see how my ideas would turn out in the end. For instance, the
> "cache item pinning" feature got dropped and replaced by an
> even more effective solution.
> Now, I got a working code base that already served many TBytes
> without complaint and many code fragments can directly be
> copied into the SVN /trunk - after due review, of course.
> What has been changed?
> * APR: improve performance when scanning a file backward
> * APR: defer (and often eliminate) seek operations
> * FSFS only: file handle cache to keep files open as long as
> feasible and to reuse their buffer content.
> * FSFS only: in-process shared fulltext and txdelta caches
> (similar to memcached but without the latency penalty)
This is great news.
I have a custom multithreaded svn server that exposes the svn_fs.h API
using an Apache Thrift style API to remote clients (actually using
ZeroC's Ice, but it's similar). I keep svn_fs_t, svn_repos_t and
svn_fs_root_t persistent in memory so I don't need to go to disk later
if I receive a request for the same revision or repository.
Are these caches static, per fs, or per-something else? Is there a way
to clear them? How is their memory use managed?
Received on 2010-07-09 02:51:31 CEST