On Sun, Dec 18, 2011 at 22:46, Stefan Fuhrmann
<stefanfuhrmann_at_alice-dsl.de> wrote:
> For interested parties,
>
> Work on said branch is done so far and I think
> it is generally ready for being merged into /trunk.
> But it is certainly a good idea to give it some
> detailed review, in particular with regard to side-
> effects on e.g. FSFS recovery code.
>
> What it does in a nutshell:
>
> * to FSFS svn_fs_t, attaches a cache for open file
> handles to reduce the number of open, lseek,
> read and close operations
> * svnserve CL and apache config option to set
> the per-process maximum of cached handles
> (default: 16)
>
> * use cached file handles for r/o access to revision
> files in FSFS
> * notify the cache after revision files have been
> written ("flush" cache entries for these files)
>
> With the repository on a linux RAM disk, it speeds
> up a "cold" export of TSVN /trunk by approx. 10%.
> Slower disks may show larger gains.
>
> If there are no major objections, I would like to merge
> the code into /trunk around mid-January.
>
Hi, Stefan!
As I stated before I'm -1 for merging file-handles cache stuff to trunk:
1. The performance gain is not significant and may vary from
environment to environment.
2. We introduce really dirty hacks. After merging your branch we have
to worry about file handles to keep them in reusable state or do not
forget to notify file handles cache to flush this handle.
3. By design handles are not intended to be cached, underlying objects
should be cached. In your branch your introduce handles to handles.
4. It seems current implementation reuses file handles even error is
occurred when working with the handle. It's potentially dangerous from
my point view.
--
Ivan Zhakov
Received on 2012-01-03 10:02:41 CET