Huge Performance Problems with large Files over http

["Max Bernhardt - extern TAGP - Tel. 3749" <Ma...@vodafone.com>]

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 ..." ;-)