Compression: client or server?

[Lisa Marie Seelye]

--=-UPrHodqtDKkD/9Ha+4JP
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-08-13 at 15:53, Brad Fitzpatrick wrote:
> I agree.
>=20
> 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=
t
> 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.
>=20
> 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=
e
> 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?


--=20
Regards,
-Lisa
<Vix ulla tam iniqua pax, quin bello vel aequissimo sit potior>

--=-UPrHodqtDKkD/9Ha+4JP
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)

iD8DBQA/OpqCy0a1Vh5Jb8URAhD4AKCVVuwQ+5GFWlKmbxeeGlKzXHOpUwCdH0QG
opqf9fTcn5xUQxaewbknq3M=
=KwUj
-----END PGP SIGNATURE-----

--=-UPrHodqtDKkD/9Ha+4JP--