[hybi] Impact of mandatory chunking (was Re: Background info: Properties of sendfile())

Maciej Stachowiak <mjs@apple.com> Fri, 06 August 2010 21:22 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59BFD28C2DC for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.532
X-Spam-Level:
X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8WIyiaIKnzP for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:22:31 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id D629728C142 for <hybi@ietf.org>; Fri, 6 Aug 2010 13:52:09 -0700 (PDT)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out4.apple.com (Postfix) with ESMTP id 9B258A7A8636 for <hybi@ietf.org>; Fri, 6 Aug 2010 13:52:41 -0700 (PDT)
X-AuditID: 11807136-b7cc9ae000004162-3e-4c5c761908b7
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id C7.95.16738.9167C5C4; Fri, 6 Aug 2010 13:52:41 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.100.119] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L6R00DUK0NT4U20@elliott.apple.com> for hybi@ietf.org; Fri, 06 Aug 2010 13:52:41 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <AANLkTimUkx8_Ssiuh4vJsgiQb2xmUzr5uAb-TgG=bjyh@mail.gmail.com>
Date: Fri, 06 Aug 2010 13:52:40 -0700
Message-id: <F6D37A7E-C176-4F79-962D-7DF61FB16492@apple.com>
References: <4C5B1695.6070704@gmx.de> <F8E2F702-9F74-4316-B3B2-D5A731409ABF@apple.com> <4C5B2029.90403@gmx.de> <AANLkTim1WeCRfcPxXUNQcVhb4+t_TtDQDv2bXaxOQ=bk@mail.gmail.com> <01098AD0-FBF4-4A61-B565-947C95722BAA@apple.com> <AANLkTi=qQSND5BvUP5+P=wJ7E8SG6NncGZH8U8+VYwZ0@mail.gmail.com> <20100806004907.GF27827@shareable.org> <C0FC87B7-C51C-4B36-BC16-DBDB0B00A20F@gbiv.com> <20100806012845.GI27827@shareable.org> <AANLkTimuvuj87qwQi_1Gjg47-gGrCsDCQ5TDd5zvOw1N@mail.gmail.com> <20100806062928.GF20057@1wt.eu> <AANLkTimUkx8_Ssiuh4vJsgiQb2xmUzr5uAb-TgG=bjyh@mail.gmail.com>
To: Jack Moffitt <jack@collecta.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "hybi@ietf.org" <hybi@ietf.org>
Subject: [hybi] Impact of mandatory chunking (was Re: Background info: Properties of sendfile())
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2010 21:22:32 -0000

On Aug 6, 2010, at 6:49 AM, Jack Moffitt wrote:

>> At least I've seen it. Haproxy happily forwards traffic at 10 Gbps
>> with only 25% of one CPU core on a 2.66 GHz Core2Duo using splice().
>> And some file sharing sites make a big use of it ! Without splice,
>> it hardly achieves 10 Gbps at 100% CPU.
> 
> It's not clear how much of the benefit we'd lose with fixed size
> lengths (and therefore mandatory chunking). At this point, it seems
> that kind of data would be valuable.
> 
> The tradeoff *seems* to be simple intermediaries versus
> sendfile()/splice() efficiency. If sendfile() is severely affected, it
> may make sense to make the intermediaries life slightly more
> complicated. If not, I think we keep their job simple.

It's not only the sender and intermediaries that are affected by mandatory chunking. The receiver is affected too. In the case of the browser as receiver, it is highly valuable to have the length up front, so the browser can either pre-allocate a memory buffer of the appropriate size, or decide to start spooling to disk right away if it knows the message will be too large to fit in memory. I imagine this will be useful in at least some cases of the server as receiver too.

Let me note also, that even without chunking at the WebSocket protocol level, receivers that would rather read a fixed size chunk at a time can still do so.

Regards,
Maciej