From: Eric Wong <email@example.com> To: Simon Eskildsen <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org Subject: Re: check_client_connection using getsockopt(2) Date: Thu, 23 Feb 2017 01:42:23 +0000 Message-ID: <20170223014223.GA15864@starla> (raw) In-Reply-To: <CAO3HKM7m7_9Fr6N8Wobqb3nqKCwJt4rxog=1ZLv_LraYeR9FUw@mail.gmail.com> Simon Eskildsen <email@example.com> 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, though... > 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 rack.hijack with. 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 perspective. (*) 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. Maybe...
next prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-22 12:02 Simon Eskildsen 2017-02-22 18:33 ` 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
Reply instructions: You may reply publically 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://bogomips.org/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170223014223.GA15864@starla \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help Archives are clonable: git clone --mirror https://bogomips.org/unicorn-public git clone --mirror http://ou63pmih66umazou.onion/unicorn-public Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox