From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from mail-oi0-x23d.google.com (mail-oi0-x23d.google.com [IPv6:2607:f8b0:4003:c06::23d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 25D3A200E0 for ; Tue, 27 Dec 2016 16:00:02 +0000 (UTC) Received: by mail-oi0-x23d.google.com with SMTP id v84sf63149581oie.1 for ; Tue, 27 Dec 2016 08:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=sender:mime-version:in-reply-to:references:from:date:message-id :subject:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=5GFxOtDBfBB8c8NbGC2nL6lQHI9K1j+TOym+m6x/gzI=; b=bui2aZL2W6BXIkh+igjAv21KkOFcskwyqevy8OmCnm3uY8kG42s4KZNjqOhJsh8mN7 zUxq9aaXiNZSGhhDVJznfhLMxYjNu3z8jzytg2LI9CDMro0WV8L+AX0Pbkxpz0gUBLBi WeWHDoh9FS5809pcGH3MAlzDkMdpFjHNVSh5xfe+sC657e3lcp9QVhFojhLoinmkN7ta 3ZVFIf84F1jfuLr8zRhot2JBxlUoXtmPwrf6xAJez8Pj3X32fTUByiw7z81ensfy6FA7 sh1Qpa8JxY3bRsPsqfyprj4QjXdyPnlfw9TxvMtGDZOwUUVT0g479YxM9HdhlnKyV3uB S27Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=5GFxOtDBfBB8c8NbGC2nL6lQHI9K1j+TOym+m6x/gzI=; b=Yc6t5Z5qX0E5Z2jUcd4SE1YWy6KF8WWLi9cREEwURb4G0T0mb/X9rm2cnCVoFXpEyj bI3i0QfaGN+boxDn5GFpxF9I+s7rKb2ic7+yHJbMLpeEk5krls1D6UG2/A7w+um8mfPy GUNcai8iBqqS3G8x9OS+bcUYzrDRk69N4m4YSglQtum5Oo2jfYwRvU/U2nxpTnbMQa+6 UOFme8hcB6N0+mf3LMTVd4nUO2r0rMhUIZZ0o3KPle1VDgP8b+f2Wpf9M9Axm3MDqHR4 UnqOD1Z8gM0KpLN5T9JXk4x2X3x4oI9dErTuCKi3Eek1YYGkNyyQ89AfVyjjE2l8QhHY J7xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=sender:x-gm-message-state:mime-version:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=5GFxOtDBfBB8c8NbGC2nL6lQHI9K1j+TOym+m6x/gzI=; b=aItJPylYC+g5UbSXt+KtqOqZxW6K+H60pDKOUYLFSbreOTZqYAKJav5WLY3qxroSxg aJZTj6eh6HqwZ31XdFv7mayEzrQg5MP1vhzCW7mH4lPY91oQt9ylAXtq93ehs6TP1JUU ONu9EBGd6uzO16jj5TyvnCY17r2VpvpBnmzZTxiqkWxMYwsvPbTiZtYyRR86VCOVwGCX QwvmuqVBQx6HVV+gw/tIXCZFFgH5qMssgtJQxSXCQS7ULjzr7KsWq09nWdr2j/ieAZuy a9QZ/akjtosg7KCiJMvj7TqtyYk1hMGK8Nxq0/Zm19VjKb+s3wAWglkWE34MT6YYnDVU wTpg== Sender: rack-devel@googlegroups.com X-Gm-Message-State: AIkVDXKE8A1eYT6N++AW8IjNK8O02wL2GX7VVP+oHSe3j96gItgjg5VNPIrhAQhBar6M4Q== X-Received: by 10.157.37.151 with SMTP id q23mr1323263ota.4.1482854401586; Tue, 27 Dec 2016 08:00:01 -0800 (PST) X-BeenThere: rack-devel@googlegroups.com Received: by 10.157.43.168 with SMTP id u37ls22747406ota.29.gmail; Tue, 27 Dec 2016 08:00:01 -0800 (PST) X-Received: by 10.157.13.110 with SMTP id 101mr9048515oti.90.1482854401302; Tue, 27 Dec 2016 08:00:01 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com. [2607:f8b0:4001:c06::234]) by gmr-mx.google.com with ESMTPS id n197si2848944itn.1.2016.12.27.08.00.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 08:00:01 -0800 (PST) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4001:c06::234 as permitted sender) client-ip=2607:f8b0:4001:c06::234; Received: by mail-io0-x234.google.com with SMTP id p42so315901192ioo.1 for ; Tue, 27 Dec 2016 08:00:01 -0800 (PST) X-Received: by 10.107.18.39 with SMTP id a39mr23096614ioj.45.1482854400864; Tue, 27 Dec 2016 08:00:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.6.13 with HTTP; Tue, 27 Dec 2016 08:00:00 -0800 (PST) Received: by 10.107.6.13 with HTTP; Tue, 27 Dec 2016 08:00:00 -0800 (PST) In-Reply-To: <20161224231512.GA21913@dcvr> References: <20161115-slow-clients-rack-vs-psgi@80x24.org> <20161224231512.GA21913@dcvr> From: James Tucker Date: Tue, 27 Dec 2016 08:00:00 -0800 Message-ID: Subject: Re: big responses to slow clients: Rack vs PSGI To: Rack Development Content-Type: multipart/alternative; boundary=001a113ff17cd137150544a5f108 X-Original-Sender: jftucker@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of jftucker@gmail.com designates 2607:f8b0:4001:c06::234 as permitted sender) smtp.mailfrom=jftucker@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , --001a113ff17cd137150544a5f108 Content-Type: text/plain; charset=UTF-8 On Dec 24, 2016 7:15 PM, "Eric Wong" wrote: Thank you for your response. As far as departing from Rack... I guess PSGI was one departure :) Looking back, I think the possibility of an ecosystem of stdlib/gems to support lightweight coroutines was lost when MRI got 1:1 threads with YARV. Fibers, Neverblock, Goliath never got the critical mass to affect stdlib or most gems after that. So yeah, I agree this really needs core/stdlib support which I doubt can still happen. Coro for Perl5 is in a bad, perhaps worse spot, even. Fibers as implemented lose their usefulness as scheduler primitives because of their thread local overloading and strict thread binding. If that was fixed they'd be able to be used like coroutines are used for scheduling elsewhere. And yet I know my brain still favors OS kernel primitives over language-level primitives; so in that way MRI/YARV today is closer to how my brain works w.r.t. non-blocking I/O combined with native threads or processes as needed. *shrug* >From a server/Io perspective this makes sense. The problem is from the apps/users perspective. They ideally need to be able to "just write" without managing buffers, non-blocking, multiplexing etc. That's what the stack solutions give them that no other solution does. I do think a write capable API is OK - that's why I introduced hijack, as imperfect as it is. Of course hijack is hard to implement correctly in the face of 1.0 and 1.1 support, especially if you try to support pipelining. The split boolean design was to allow cow cloneable environment objects only allocating space for bool and some buffer pointers in the case of most requests, with the hijack methods being localled from some preexisting server context. Yet, it seems the Ruby mainstream is content with primitive servers like unicorn. I often wonder if the unintentional popularity of unicorn set the Ruby ecosystem back 5-10 years in terms of concurrency. Likely so, but the damage is done :< In my defense, I suck at marketing, so it's not my fault. Unicorn was about deploying rails easily for most people, which it really did. Thin had some other challenges, from the fact that the EM build often had issues with openssl to unintended buffering issues that are fine for short requests but very bad for long requests. Goliath tried, with stronger marketing, to address the concurrency issues, but Goliath baseline performance was too far behind more basic approaches to make it a viable option. Anyone who benched their apps and/or didn't turned explicitly for it will have seen this very clearly. Anyways, my original post was really a reporting-in-from-hiatus message. I haven't done anything new with server design in over 5 years, and don't expect I will in the future; just occasional janitorial work. yahns was merely a repackaging and consolidation of findings from Rainbows! as a "best of" release with some warts removed. I'd love to see it happen. I think about doing something periodically, but for general user use cases its quite a lot of work (as one has to write good primitives first). I don't really deploy much ruby anymore, my last bit is probably going away by 2018. Maybe I'll be back, maybe work will bring me back, but for now, it's someone else race. Happy Christmas and New years! -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --001a113ff17cd137150544a5f108 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 24, 2016 7:15 PM, "Eric Wong" <e@80x24.org> wrote:
Thank you for your= response.

As far as departing from Rack...=C2=A0 I guess PSGI was one departure :)
Looking back, I think the possibility of an ecosystem of
stdlib/gems to support lightweight coroutines was lost when MRI
got 1:1 threads with YARV.=C2=A0 Fibers, Neverblock, Goliath never
got the critical mass to affect stdlib or most gems after that.
So yeah, I agree this really needs core/stdlib support which I
doubt can still happen.=C2=A0 Coro for Perl5 is in a bad, perhaps
worse spot, even.

<= /div>
Fibers as implemented lose their usefulness as sched= uler primitives because of their thread local overloading and strict thread= binding. If that was fixed they'd be able to be used like coroutines a= re used for scheduling elsewhere.

And yet I know my brain still favors OS kernel primitives over
language-level primitives; so in that way MRI/YARV today is
closer to how my brain works w.r.t. non-blocking I/O combined
with native threads or processes as needed.=C2=A0 *shrug*
<= /div>

From a serve= r/Io perspective this makes sense. The problem is from the apps/users persp= ective. They ideally need to be able to "just write" without mana= ging buffers, non-blocking, multiplexing etc. That's what the stack sol= utions give them that no other solution does. I do think a write capable AP= I is OK - that's why I introduced hijack, as imperfect as it is. Of cou= rse hijack is hard to implement correctly in the face of 1.0 and 1.1 suppor= t, especially if you try to support pipelining. The split boolean design wa= s to allow cow cloneable environment objects only allocating space for bool= and some buffer pointers in the case of most requests, with the hijack met= hods being localled from some preexisting server context.

Yet, it seems the Ruby mainstream is content with primitive
servers like unicorn.=C2=A0 I often wonder if the unintentional
popularity of unicorn set the Ruby ecosystem back 5-10 years in
terms of concurrency.=C2=A0 Likely so, but the damage is done :<
In my defense, I suck at marketing, so it's not my fault.

Unicorn = was about deploying rails easily for most people, which it really did. Thin= had some other challenges, from the fact that the EM build often had issue= s with openssl to unintended buffering issues that are fine for short reque= sts but very bad for long requests.

Goliath tried, with stronger marketing, to address the concurre= ncy issues, but Goliath baseline performance was too far behind more basic = approaches to make it a viable option. Anyone who benched their apps and/or= didn't turned explicitly for it will have seen this very clearly.

<= div class=3D"gmail_quote">
Anyways, my original post was really a reporting-in-from-hiatus
message.=C2=A0 I haven't done anything new with server design in over 5 years, and don't expect I will in the future; just occasional
janitorial work.=C2=A0 yahns was merely a repackaging and
consolidation of findings from Rainbows! as a "best of" release with some warts removed.

I'd love to see it happen. I think about = doing something periodically, but for general user use cases its quite a lo= t of work (as one has to write good primitives first). I don't really d= eploy much ruby anymore, my last bit is probably going away by 2018. Maybe = I'll be back, maybe work will bring me back, but for now, it's some= one else race.

Happy Chr= istmas and New years!


--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
--001a113ff17cd137150544a5f108--