unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: Boaz Segev <boaz@2be.co.il>
Cc: unicorn-public@bogomips.org
Subject: Re: Please join the Rack Specification discussion for `env['upgrade.websocket']`
Date: Sat, 6 Aug 2016 04:59:18 +0000	[thread overview]
Message-ID: <20160806045918.GA31857@starla> (raw)
In-Reply-To: <202FC1D8-3042-4CBF-9DEA-85D1BEA080F3@2be.co.il>

Boaz Segev <boaz@2be.co.il> wrote:
> Running two (or more) event loops, each with it's own
> resources, is wasteful and promotes needless context switches.
> There is no reason to hijack a socket when the server can
> easily provide callbacks for IO related events using it's
> existing established event loop.

As Michael said, WS is a really bad fit for unicorn :)

> This alone should provide a performance boost. There are other
> considerations as well, but I think they all derive from this
> core principle of having the web server retain control over
> all network IO concerns.

For anybody else writing an epoll-based server with multiple
epoll-based event loops in different threads, the following is
good ordering; relatively cheap and scalable:

	epoll_ctl(original_epfd, EPOLL_CTL_DEL, client_fd, NULL);
	epoll_ctl(websocket_epfd, EPOLL_CTL_ADD, client_fd, &ev);

Change the order, and it's slower and less scalable:

	/* in other words, don't do this in this order */
	epoll_ctl(websocket_epfd, EPOLL_CTL_ADD, client_fd, &ev);
	epoll_ctl(original_epfd, EPOLL_CTL_DEL, client_fd, NULL);

The former ensures a simple topology where the file behind
client_fd only exists in one eventpoll rbtree at a time.  The
latter creates a complex topology which needs to do additional
locking and scanning to prevent infinite loops.

This is true since Linux 3.13, commit 67347fe4e632633
("epoll: do not take global 'epmutex' for simple topologies")

> like hijacking, it's optional.
> Unicorn was design for very specific use cases, so I
> definitely understand if this might not be as interesting for
> you. 

Yes, unicorn itself will never have a multi-client-aware event
loop.  It is out-of-scope for its design, it seems WebSockets
usually have idle times which would cause any server with the
design of unicorn to fall over.  unicorn cannot even handle
HTTP/1.1 persistent connections.

> However, I do think your experience as developers could help
> enrich us all. If you have any comments or anything to add
> regarding the proposed `websocket.upgrade` specification, your
> voice is welcome:

Sorry, not interested, and definitely not touching centralized
message boards :>

      parent reply	other threads:[~2016-08-06  4:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-05 23:49 Please join the Rack Specification discussion for `env['upgrade.websocket']` Bo
2016-08-06  1:01 ` Eric Wong
2016-08-06  3:09   ` Boaz Segev
2016-08-06  4:10     ` Michael Fischer
2016-08-06  7:37       ` Boaz Segev
2016-08-09  1:08         ` Sam Saffron
2016-08-09  2:42           ` Eric Wong
2016-08-09  3:17           ` Boaz Segev
2016-08-06  4:59     ` Eric Wong [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160806045918.GA31857@starla \
    --to=e@80x24.org \
    --cc=boaz@2be.co.il \
    --cc=unicorn-public@bogomips.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).