From: Eric Wong <firstname.lastname@example.org>
To: Simon Eskildsen <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
Subject: Re: check_client_connection using getsockopt(2)
Date: Thu, 23 Feb 2017 01:42:23 +0000 [thread overview]
Message-ID: <20170223014223.GA15864@starla> (raw)
Simon Eskildsen <firstname.lastname@example.org> wrote:
<snip> Thanks for the writeup!
Another sidenote: It seems nginx <-> unicorn is a bit odd
for deployment in a containerized environment(*).
> I meant to ask, in Raindrops why do you use the netlink API to get the
> socket backlog instead of `getsockopt(2)` with `TCP_INFO` to get
> `tcpi_unacked`? (as described in
> http://www.ryanfrantz.com/posts/apache-tcp-backlog/) We use this to
> monitor socket backlogs with a sidekick Ruby daemon. Although we're
> looking to replace it with a middleware to simplify for Kubernetes.
> It's one of our main metrics for monitoring performance, especially
> around deploys.
The netlink API allows independently-spawned processes to
monitor others; so it can be system-wide. TCP_INFO requires the
process doing the checking to also have the socket open.
I guess this reasoning for using netlink is invalid for containers,
> I was going to use `env["unicorn.socket"]`/`env["puma.socket"]`, but
> you could also do `env.delete("hijack_io")` after hijacking to allow
> Unicorn to still render the response. Unfortunately the
> `<webserver>.socket` key is not part of the Rack standard, so I'm
> hesitant to use it. When this gets into Unicorn I'm planning to
> propose it upstream to Puma as well.
I was going to say env.delete("rack.hijack_io") is dangerous
(since env could be copied by middleware); but apparently not:
rack.hijack won't work with a copied env, either.
You only need to delete with the same env object you call
But calling rack.hijack followed by env.delete may still
have unintended side-effects in other servers; so I guess
we (again) cannot rely on hijack working portably.
> Cool. How would you suggest I check for TCP_INFO compatible platforms
> in Unicorn? Is `RUBY_PLATFORM.ends_with?("linux".freeze)` sufficient
> or do you prefer another mechanism? I agree that we should fall back
> to the write hack on other platforms.
The Raindrops::TCP_Info class should be undefined on unsupported
platforms, so I think you can check for that, instead. Then it
should be transparent to add FreeBSD support from unicorn's
(*) So I've been wondering if adding a "unicorn-mode" to an
existing C10K, slow-client-capable Ruby/Rack server +
reverse proxy makes sense for containerized deploys.
next prev parent reply other threads:[~2017-02-23 1:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAO3HKM49+aLD=KLij3zhJqkWnR7bCWVan0mOvxD85xfrW8RXOw@mail.gmail.com>
2017-02-22 18:33 ` check_client_connection using getsockopt(2) Eric Wong
2017-02-22 20:09 ` Simon Eskildsen
2017-02-23 1:42 ` Eric Wong [this message]
2017-02-23 2:42 ` Simon Eskildsen
2017-02-23 3:52 ` Eric Wong
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/raindrops/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).