Compression: client or server?

Lisa Marie Seelye
Wed, 13 Aug 2003 16:07:30 -0400

Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-08-13 at 15:53, Brad Fitzpatrick wrote:
> I agree.
> The issue then is stats, though.  It'd be interesting to know how much
> physical vs. logical data is in memcache.  Based on that, you could adjus=
> the compression threshold on the clients.  I imagine adding an option to
> the Perl MemCachedClient API that says, "Compress after this size".

This is a good idea for the API, but not really relevant to the server,
as long as the server keeps those flags intact!!

> At lunch just now Evan and I realized another point to add it to the
> server, though:  what if somebody had more memcache servers than web
> nodes?  But we don't buy this argument, because in our experience you
> can't just _buy_ a memcache machine.  We were unable to find a system or
> parts vendor who could get us a machine with a crap processor and tons of
> RAM.
> So, yeah:  compression definitely client-side, but the server should do
> stats by the client sending more data about how much it shrank it to.  Se=
> any problem with that?

I don't see what difference it makes to the server if all the data is
data.  Whether or not its a Shakespearean play or a compressed jpeg what
should the server care?

<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>

Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.2.2 (GNU/Linux)