Huge Performance Problems with large Files over http

Hi,

in general subversion works fine for us, but we have massive performance
problems
with 'svn checkout' (and possibly other commands) of large files over
http.

We are using
    svn 1.2.0 (r10424)
    neon 0.24.7
    bdb 4.2.52
    apache 2.0.49
    openssl 0.9.7d

The whole thing is running under solaris 8 on a two-processor sunfire240
with
2GB RAM and Gigabit-Ethernet.

The repo uses the bdb - backend.

A checkout of a ca. 20-30 libraries (3 of them are larger than 10MB, the
largest is
about 40MB) takes nearly one and a half hours!

These are the entries in the .svn/tmp/text-base directory during the
checkout:

-rw-r----- 1 svn svn 1529076 Jul 27 14:23
COS403_rt.lib.svn-base
-rw-r----- 1 svn svn 2002400 Jul 27 14:23
COS403_rtd.lib.svn-base
-rw-r----- 1 svn svn 6801642 Jul 27 14:25
omniCodeSets4d.lib.svn-base
-rw-r----- 1 svn svn 530438 Jul 27 14:25
COSDynamic403_rt.lib.svn-base
-rw-r----- 1 svn svn 295484 Jul 27 14:25
python15.lib.svn-base
-rw-r----- 1 svn svn 178936 Jul 27 14:25
omnisslTP.lib.svn-base
-rw-r----- 1 svn svn 4421310 Jul 27 14:25
omniORB4.lib.svn-base
-rw-r----- 1 svn svn 4648676 Jul 27 14:25
omniDynamic4.lib.svn-base
-rw-r----- 1 svn svn 3017702 Jul 27 14:26
omnisslTPd.lib.svn-base
-rw-r----- 1 svn svn 1327374 Jul 27 14:26
omniORB403_rt.lib.svn-base
-rw-r----- 1 svn svn 33470 Jul 27 14:26
omnisslTP40_rt.lib.svn-base
-rw-r----- 1 svn svn 1985560 Jul 27 14:26
omniDynamic403_rt.lib.svn-base
-rw-r----- 1 svn svn 26542 Jul 27 14:26
msvcstub.lib.svn-base
-rw-r----- 1 svn svn 3380042 Jul 27 14:26 COS4.lib.svn-base

-rw-r----- 1 svn svn 632360 Jul 27 14:26
msvcstubd.lib.svn-base
-rw-r----- 1 svn svn 11617398 Jul 27 14:29
COS4d.lib.svn-base
-rw-r----- 1 svn svn 8761988 Jul 27 14:31
COSDynamic4d.lib.svn-base
-rw-r----- 1 svn svn 12680 Jul 27 14:31
omniCodeSets403_rt.lib.svn-base
-rw-r----- 1 svn svn 887290 Jul 27 14:31
COSDynamic403_rtd.lib.svn-base
-rw-r----- 1 svn svn 37968 Jul 27 14:31
omnithread.lib.svn-base
-rw-r----- 1 svn svn 23090 Jul 27 14:31
omniCodeSets403_rtd.lib.svn-base
-rw-r----- 1 svn svn 40390862 Jul 27 15:23
omniORB4d.lib.svn-base
-rw-r----- 1 svn svn 73928 Jul 27 15:24
omnithreadd.lib.svn-base
-rw-r----- 1 svn svn 21425038 Jul 27 15:36
omniDynamic4d.lib.svn-base
-rw-r----- 1 svn svn 20674 Jul 27 15:36
omnithread30_rt.lib.svn-base
-rw-r----- 1 svn svn 49862 Jul 27 15:36
omnisslTP40_rtd.lib.svn-base
-rw-r----- 1 svn svn 1800266 Jul 27 15:36
omniORB403_rtd.lib.svn-base
-rw-r----- 1 svn svn 20756 Jul 27 15:36
omnithread30_rtd.lib.svn-base
-rw-r----- 1 svn svn 2656256 Jul 27 15:36
omniDynamic403_rtd.lib.svn-base

The checkout of the omniORB4d.lib alone took nearly one hour ...

Interestingly the svn client uses 100% of one processor and grows to
more than 160 MB
in size during the checkout.

We tried this with and without http compression, the results are the
same.

Also we tried to do the checkout using direct access to the repo with
file:///. This time the
checkout took less than 10 minutes! (sadly this is no possible longterm
solution ...)

Although we really like subversion, this could very well be a killer
criterium ...

Anybody know what we can do?

Regards,
               Max Bernhardt

--
"There is no spoon ..." ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org