On 07/03/2010 03:28 PM, Stefan Fuhrmann wrote:
Go and grab your share at
https://tortoiseanalyze.svn.sourceforge.net/svnroot/tortoiseanalyze/OptimizedSVN/branches/prototype
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
rejected.
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?
Thanks!
Blair
