Re: [hybi] Background info: Properties of sendfile()

Jamie Lokier <jamie@shareable.org> Fri, 06 August 2010 18:01 UTC

Return-Path: <jamie@shareable.org>
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 453663A69D6 for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 11:01:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
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 dqRVZACfVjNo for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 11:01:08 -0700 (PDT)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 13AFE3A6924 for <hybi@ietf.org>; Fri, 6 Aug 2010 11:01:07 -0700 (PDT)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1OhREU-0006uQ-EW; Fri, 06 Aug 2010 19:01:26 +0100
Date: Fri, 06 Aug 2010 19:01:26 +0100
From: Jamie Lokier <jamie@shareable.org>
To: Willy Tarreau <w@1wt.eu>
Message-ID: <20100806180126.GP27827@shareable.org>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20100806062928.GF20057@1wt.eu>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: "Roy T. Fielding" <fielding@gbiv.com>, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] 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 18:01:09 -0000

Willy Tarreau wrote:
> On Thu, Aug 05, 2010 at 06:47:48PM -0700, Roberto Peon wrote:
> > Thus my statement of "theoretical" benefits.
> > I've not seen the benefits of either splice or sendfile yet.
> 
> 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.
> 
> Anyway, it's unclear to me why we would need to send large amounts
> of data over WebSockets. File serving could well be performed by
> the web server itself.

Some examples:

  - You've got a web app which carries user-generated short messages,
    that should not be fragile when a user decides to send a long one.
    For example an IM client, when a user tries cutting-and-pasting 20
    pages of text (70kB) into an entry, there is no good reason for
    that to crash the app.  (Certainly not just because of a WebSocket
    limit being hit.)  Yes, users occasionally do this sort of thing.

  - Dynamic HTML updates sent from the server (expect lots of this in
    web apps).  Live wiki editing, shared documents etc.  They send
    HTML fragment update messages to update the browser.  Normally
    they'll be small, but under various circumstances (including
    temporary network outage so the user queues up a lots of deltas),
    an HTML update may occasionally be larger than usual.  It should
    just work, without invoking rarely-used code paths.

  - The old IM again, with inline smileys and avatars.  If you need to
    get the latency down you may encode these small images into an
    update message.  They're small, but vary in size and may
    occasionally exceed some arbitrary small limit, if there is one.

In a nutshell: The WS API should not hold surprises, cause
unnecessarily fragility in the apps using it, or require apps to have
exceptional code paths, where that's easy to avoid.

-- Jamie