Re: Will HTTP/2.0 be green ?

On Sun, 01 Jun 2014 22:00:16 +0200, 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.

With the simple compression we are looking at you are likely to see  
performance gains AND power savings. My somewhat dated data says that  
transmitting one bit on wifi takes the same amount of energy as 500 ARM  
instructions. Gzip is surprisingly well positioned in compression ration  
vs. CPU cycles. We are doing way less work here, and saving quite a lot of  
data and packages. As Roberto pointed out, getting the data to the device  
fast so the radio can move to low energy mode quickly is important, and  
much more important than compression on mobile.

We did energy benchmarking on real devices with something close to HTTP/2  
last year, and the major conclusion is that it comes down use case and  
implementation. If you correctly push dependent data you'll dramatically  
reduce radio high energy time (but as always, 50% of the energy is spent  
on getting tracking pixels from ad servers). If you on the other hand send  
ping messages to keep TCP and radio hot, you'll drain the battery in no  
time. If you benchmark load-as-you-scroll pages you'll get horrible  
results regardless of protocol, and any difference is a rounding error.

Having real numbers on a good implementation would of course be very  
interesting.

/Martin Nilsson


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Received on Sunday, 1 June 2014 22:36:54 UTC