Compression: client or server?
Lisa Marie Seelye
Wed, 13 Aug 2003 16:07:30 -0400
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
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----