On Wed, Aug 1, 2012 at 9:56 PM, slaventii <xumuku_at_gmail.com> wrote:
>> Huh? How do you arrive at 23 %? According to these numbers, https is
>> almost twice as fast here.
>>
> Sorry for mistake. Should be:
> up svn:// ~ 0m 19sec
> up https:// ~ 0m 35 sec
> up svn vs https perf, % ~ > 23%
Okay, got it.
>> That could very well be the reason here why your tests with 1.7 server
>> are slower. I suppose it's reasonable to expect that
>> SVNCompressionLevel 0 makes checkout slower on a 100 Mbit connection.
>> On a 1 Gbit connection the situation could be different, and it might
>> make it faster because CPU (for compression) might become the
>> bottleneck.
>>
>> It might be interesting to repeat your tests with 1.7 server with a
>> default SVNCompressionLevel (which would then be the same compression
>> as your older server).
>
> As I know compression appeared only in svn 1.7 and a didn't make any
> setup with compression level in svn 1.5.3 and 1.6.17.
> "Subversion 1.7 offers the --compression (-c) option to svnserve and
> the SVNCompressionLevel directive for mod_dav_svn. Both accept a value
> which is an integer between 0 and 9 (inclusive), where 9 offers the
> best compression of wire data, and 0 disables compression altogether."
If I understand correctly, the older versions of svn ( < 1.7) always
did wire-compression, but it wasn't configurable (probably with the
default compression level, i.e. 5). In 1.7 the configuration knob was
exposed so you can now manually tweak the desired compression level
(to save on CPU at the expense of some more wire-overhead). To get the
same behavior as with older versions, you can just omit the
configuration parameter, and it will still use the default of 5.
I don't know a lot of the details, but I seem to remember that the
wire-compression doesn't really buy you much, because the actual data
(the delta's that are transferred during checkout or update) is
already compressed. So it made sense to be able to disable that part
of the compression.
> I done some tests with compression=9, but by my mistake it was with client 1.5.4
> Will try again with client 1.7.4 and default compression=5 and max=9.
>
> First test result:
> co https:// - 39m 17sec - compression level =9
Okay, please try again also with compression level = 5 (or just
without the configuration directive, that should be the same).
I'm getting a bit confused now between all the tests you did (checkout
was almost twice as fast with the 1.5 client against 1.7 server as
with the 1.7 client against the same server?? If that's true, we might
need to know more about the client system (e.g. on which filesystem
are you creating the working copy). Or was it with the older 1.5
server that svn:// was a lot faster?).
It might be better to start a new thread (with appropriate subject,
because this thread isn't really about "Subversion authentication via
SASL GSSAPI" anymore), with a new overview of the tests you did.
Also, be careful with the caching effects of the 1.7 server: a second
run against the same data will usually be a lot faster because all the
fulltexts will be cached in memory. So maybe you should run the test a
couple of times, ignore the first run, and then take the average of
the other runs (or if you want to test the "cold" performance, disable
the fulltext caching and/or restart the server process between each
run or something like that).
> cat /etc/apache2/mods-enabled/dav_svn.conf
> <IfModule dav_svn_module>
> # Enable a 1 Gb Subversion data cache for both fulltext and deltas.
> SVNInMemoryCacheSize 1048576
> SVNCacheTextDeltas On
> SVNCacheFullTexts On
> SVNCompressionLevel 9
> SVNAdvertiseV2Protocol On
> </IfModule>
>
>>
>> Some tests with the same hardware/software combinations over a 1 Gbit
>> connection might also be very interesting, but I suppose it'll be hard
>> for you to set up this environment.
>
> You are right, but is possible. When I have more free time.
Cool, that would be awesome :-).
--
Johan
Received on 2012-08-01 22:51:55 CEST