From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 568F9208EB for ; Wed, 8 Aug 2018 11:14:44 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 6994E120D5F; Wed, 8 Aug 2018 20:14:41 +0900 (JST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by neon.ruby-lang.org (Postfix) with ESMTPS id AC99F120D5F for ; Wed, 8 Aug 2018 20:14:34 +0900 (JST) Received: by mail-io0-f174.google.com with SMTP id k16-v6so1434368iom.12 for ; Wed, 08 Aug 2018 04:14:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=f5YDk+2i+NICGZy0hGvFUgWRmDG5vVcp06UEMw12NU4=; b=J2vD66OL58hfV3kI08z8kSW1K858aW6Rq6c+HdnAJ44R6I68+2jI35IGZ8kpYDzYuD nz9i4pBM1EHlJd9yD+e5d4yucJQJL4f06YMwRanBS6PmCtOh6xj22GkLmxojBET6SWq3 EbU9qRUriJTzymWle4MiYpNGswC5spoRLanl3fFwoU4iTgxqpElFlvtYkcfhw5/RY4x3 hEb9cy8WDj70gTmXYf7dOWyHksxS7oGol+TnF1g/R1kkpc1/MnHVIDpMb/F957CqcDwN O1fbuhjH85gnCfGqFVomKe+DtfbIfIyyUwHV8hkEEuWKz9NEwFA0SY/7LkGov9ujghkI Z64Q== X-Gm-Message-State: AOUpUlFu2s3ulU3ECVDMCVDHT3hhMNgUPaEk6PtBunN4qQrBf5B59WFB UJmlrGTwJrbn1U0HBkmHU8bqE/va5YU53F63+Od8fNdt X-Google-Smtp-Source: AA+uWPwRjRdruqyVKFKOHFGdWoHNX7oQmgbkYlFVhSL2VFOxrGUUkbZxIWAdd4IsaD/lYrzFyUjTFzQaHPOiUbJ8rJg= X-Received: by 2002:a6b:320c:: with SMTP id y12-v6mr1798286ioy.127.1533726872206; Wed, 08 Aug 2018 04:14:32 -0700 (PDT) MIME-Version: 1.0 References: <20180808084859.6feyevl3skswqn6k@dcvr> In-Reply-To: <20180808084859.6feyevl3skswqn6k@dcvr> From: Matthew Kerwin Date: Wed, 8 Aug 2018 21:14:25 +1000 Message-ID: To: Ruby developers X-ML-Name: ruby-core X-Mail-Count: 88352 Subject: [ruby-core:88352] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" [snipping some bits, because I can only speak to what I know] On Wed, 8 Aug 2018 at 18:50, Eric Wong wrote: > > samuel@oriontransfer.net wrote: > > > In particular, when handling HTTP/2 with multiple streams, > > it's tricky to get good performance because utilising multiple > > threads is basically impossible (and this applies to Ruby in > > general). With HTTP/1, multiple "streams" could be easily > > multiplexed across multiple processes easily. > > I'm no expert on HTTP/2, but I don't believe HTTP/2 was built > for high-throughput in mind. By "high-throughput", I mean > capable of maxing out the physical network or storage. > It was originally invented to reduce perceived latency, both in terms of time-to-first-paint and time-to-last-byte, in solitary servers as well as data centres and CDNs. As such throughput was definitely a goal, but not the only one. There is some synchronisation: the server has to read a few bytes of each frame it receives before it can demux them to independent handlers; and when transmitting you have to block for CONTINUATION frames if any are in progress, and for flow control if you're sending DATA. But aside from those bottlenecks, each request/response can be handled completely in parallel. Does that really have that big of an impact on throughput? > > At least, multiplexing multiple streams over a single TCP > connection doesn't make any sense as a way to improve > throughput. Rather, HTTP/2 was meant to reduce latency by > avoiding TCP connection setup overhead, and maybe avoiding > slow-start-after-idle (by having less idle time). In other > words, HTTP/2 aims to make better use of a > heavy-in-memory-but-often-idle resource. > It shouldn't be that hard to saturate your network card, if you've got enough data to write, and the other end can consume it fast enough. The single TCP connection and application-layer flow control is meant to avoid problems like congestion and bufferbloat, on top of reducing slow-start, TIME_WAIT, etc. so throughput should in theory be pretty high. I guess ramming it all into a single TLS stream doesn't help, as there is some fairly hefty overhead that necessarily runs in a single thread. I'd like to say that's why I argued so hard for to be included in the spec, but it's actually just coincidental. > > > What this means is that a single HTTP/2 connection, even with > > multiple streams, is limited to a single thread with the > > fiver-based/green-thread design. > > > I actually see two sids to this: It limits bad connections to > > a single thread, which is actually a feature in some ways. On > > the other hand, you can't completely depend on multiplexing > > HTTP/2 streams to improve performance. > > Right. > > > On the other hand, any green-thread based design is probably > > going to suffer from this problem, unless a work pool is used > > for actually generating responses. In the case of > > `async-http`, it exposes streaming requests and responses, so > > this isn't very easy to achieve. > Hmm, I think that's what I just said. But then, horses for courses -- if a protocol is designed one way, and an application is designed another, there won't be a great mesh. > > Exactly. As I've been say all aalong: use different concurrency > primitives for different things. fork (or Guilds) for > CPU/memory-bound processing; green threads and/or nonblocking > I/O for low-throughput transfers (virtually all public Internet > stuff), native Threads for high-throughput transfers > (local/LAN/LFN). > > So you could use a green thread to coordinate work to the work > pool (forked processes), and still use a green thread to serialize > the low-throughput response back to the client. > > This is also why it's desirable (but not a priority) to be able > to migrate green-threads to different Threads/Guilds for load > balancing. Different stages of an application response will > shift from being CPU/memory-bound to low-throughput trickles. > Yeah, all of this. [snipped the rest] Cheers -- Matthew Kerwin https://matthew.kerwin.net.au/