Simon Eskildsen <[email protected]> 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... -- unsubscribe: [email protected] archive: https://bogomips.org/unicorn-public/
