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

Re: Large Frame Proposal

From: Michael Sweet <msweet@apple.com>
Date: Tue, 08 Jul 2014 08:52:39 -0400
Cc: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-id: <ECCA0A6B-6273-493C-A55A-7AA89166C788@apple.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
On Jul 8, 2014, at 8:45 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> ...
> ‚ÄčI did some tests 16383 vs 65535 DATA payload performance in nghttp2 implementation on my desktop PC.
> The result is 64K version performed better by 1%, which I think is negligible.
> Maybe embedded devices like printers are far more sensitive.  For server side software and desktop client, payload size is not so much concern, no?  Are there anyone who actually measured these settings on their HTTP/2 proxy implementations?

For a printer, every chunk/frame of data gets passed off to the print engine for processing.  If the chunk doesn't contain enough information for a single pass of the print head, processing gets interrupted and you take a big performance hit.  Remember, printers and other embedded devices don't have desktop processors in them.

I think a useful rule-of-thumb is to ensure that a client or server can supply enough data to allow useful work to be done while the next frame is coming in.  If all you have is a small fragment then that time is wasted and the user will perceive poor performance, stuttering video, etc.

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 8 July 2014 12:53:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC