bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GZip level restriction


From: Derek Price
Subject: Re: GZip level restriction
Date: Fri, 20 May 2005 17:10:24 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Jones wrote:

>Derek Price writes:
>
>>I discussed adding a compression level restriction on the server as a
>>work-around for another bug that has since been fixed a few months back.
>
>
>I don't think hard restrictions are a good idea. The "best" compression
>level depends on the total system: the server machine, the client
>machine, and the communication path between them. The server doesn't
>know enough about the whole system to impose absolute restrictions. If
>I'm at the other end of a 300bps phone line, I want -z9 no matter how
>much CPU time it takes. If I'm trying to debug the connection, I want
>-z0 even if the server is at the other end of a 300bps phone line.
>Since the client is most likely to have an intelligent operator behind
>it who *can* determine the properties of the entire system, I think the
>server should always try to provide what the client asks for.


I don't agree.  First off, once Min and Max configs are implemented, an
adminstrator who agrees with you can simply not touch their config file
or explicitly set MinCompressionLevel=0 and MaxCompressionLevel=9 and
allow users to make their own decision about what level is best.

Secondly, if I am an administrator running a 200Mhz server behind a
high-speed DSL, I might want to set MaxCompressionLevel=0 or 1 depending
on how I felt about hard errors and avoid trusting any tom, dick or
harry to get it right and not bring my server to a crawl.  This actually
applies to an admin running a 3GHz server behind a T1 with enough users
that -z9 can still bog down the system when 20 of them hit the server at
once.  A max compression level of, say, 3, might double the number of
clients that can hit the server before it reaches maximum load.

This is especially relevant for admins dealing with lazy users out there
like me who run on fast client machines behind a medium-speed DSL and
lazily specify -z9 in their .cvsrc for all servers.

Similarly, if my server is up on a fast machine behind a slow modem,
perhaps I could confidently set my MinCompressionLevel=9.

In short, there are scenarios where it makes sense for the server admin
to want to restrict the compresssion level, this feature wouldn't be
disabling any old functionality, and I am offering to do the work. 
Where is the harm?

>On the other hand, it would be nice if there were a way to specify a
>default compression level or range of levels (both for the server and
>the client) that could be used in the absence of any explicit
>specification by the user. Of course, reconciling conflicting defaults
>could be an interesting challenge.


To some extent this would be happening with my proposed change.  A
client that had requested -z9 on a fast machine would always compress
their data at level 9, but the server would only compress its data at
whatever maximum level had been set, limiting the load on its CPU.

Similarly for a client -z3 and a server with a min level of 9.  The
client would compress at 3 and the server at 9, saving most the
bandwidth and not bombing the client CPU.

Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjlJALD1OTBfyMaQRAqeeAKDlAgwm32k1C5WoXaPjPZuv6vGXBQCfZv6+
s8/5+7gP1IHGn/ZDh7/m998=
=5OIj
-----END PGP SIGNATURE-----






reply via email to

[Prev in Thread] Current Thread [Next in Thread]