[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Large Repositories - related to Re: Issuezilla #1350 -- update

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-07-17 20:20:04 CEST

Russell Glaue <rglaue@cait.org> writes:

> Maybe I am wrong, but I thought it was best to not turn
> http-compression off unless necessary. What are the disadvantages
> to turning http-compression off?

Even with compression turned off, svn still sends file contents in as
blocks of 'svndiff' data, which is *already* compressed. If you
activate generic HTTP compression, all this does is compress the XML
repsonse bodies coming back from the server, and those bodies
generally tend to be tiny compared to file data. You won't notice
much difference at all.

Another reason to stop using compression is for your server's health.
If the server needs to send back a 30meg repsonse, mod_deflate will
currently buffer the *entire* thing in memory, rather than streaming
it. Your httpd processes are going to get huge.

Finally, if you allow the server to buffer the whole response, it's
likely that you're *increasing* the overall time of your update or
commit. Instead of server-streaming and client-parsing happening in
parallel, you're now forcing them to operate in series. While your
svn clients "wait" for 3 minutes for the server to reply, that's time
they could be using to parse the response instead.

So please, either compile your apache server --without-mod-deflate (or
whatever the proper switch is), or have all your svn clients set
"http-compression = no".

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 17 20:23:13 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.