W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Will HTTP/2.0 be green ?

From: Mike Belshe <mike@belshe.com>
Date: Sun, 1 Jun 2014 14:32:48 -0700
Message-ID: <CABaLYCvTVJ+6nvFEnhKFyn-dYvSGNhJBsmpfhAAGtVdhj_gs0w@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
I would be interested in seeing a useful study here.  However, the best
study would be one done in production environments rather than on simulated
devices with simulated models.  It would just be really hard to get a
realistic model.

Regardless, however, using less power wasn't an of objective in building
HTTP.  To revisit the requirements at this late stage is not a good idea.
 We should stick to the plan.

Mike





On Sun, Jun 1, 2014 at 1:00 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

>
> In the discussion about compression, and for that matter
> encryption, we need to talk a bit about greenhouse gasses.
>
> Any one microsecond, any one kilobyte of extra per-hop cost per
> HTTP request, is going to scale into remarkable amounts of greenhouse
> gasses by the time it is scaled up across the WWW.
>
> Ideally, we should be able to show that processing the same
> workload with HTTP/2.0 takes no more energy than with HTTP/1.1,
> and preferably less.
>
> A small power increment for significant performance gains can
> probably be "sold" with some hand-waving.
>
> Having HTTP/2.0 use significantly more energy than HTTP/1.1
> would make the protocol a non-starter.  Just imagine the
> gleeful CS/EE student papers and resulting headlines.
>
> Poul-Henning
>
> PS:  Speaking from a lot of experience, the most manageable way to
> measure power consumption realtive to workload is to use really
> small computers, RasberryPI, BeagleBone, Soekris etc. where the
> measurements can be done on the low voltage DC supply.
>
> If anybody wants to persue this, I'll be happy to help out.
>
> Drop me email.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>
Received on Sunday, 1 June 2014 21:33:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC