An optimization that applies to you only if you are on DragonFly, running nginx, and dealing with many requests: there’s a sysctl that specifically increases available sockets, which will decrease latency; Sepherosa Ziehau’s commit message gives stats.
7 Replies to “Kevent, reported sockets, and nginx on DragonFly”
Comments are closed.
Sepherosa continues to impress. And you have to love his thorough benchmarking.
Has anyone found a thorough review of DragonflyBSD 5.0 for me to read?
My last comment didn’t sounds right.
What I meant to say is “has anyone found a good Dfly 5.0 review. I’m extremely interested in reading about 5.0”
I haven’t seen anything – but operating system reviews are not that common.
I’d like to sit down and go through a bunch of steps with HAMMER2, and use that as an article basis… but I just plain haven’t had time because of a recent job switch. It’s been a rush just to get In Other BSDs/Lazy Reading together in time for the weekend. Soon, I hope, without any definition of how soon “Soon” is.
I wonder if Cloudflare reporting high latency with NGINx /Linux / REUSE is related to what Sephorosa encountered and fixed in Dfly
See these two links
https://blog.cloudflare.com/the-sad-state-of-linux-socket-balancing/
https://news.ycombinator.com/item?id=15540011
I only see REUSEPORT reduces latency and improves performance on Dfly. If Linux had issue, it was their own. And for nginx on Linux there are only two choice:
1, accept one socket each time. As far as I tested, this gives worse performance on Dfly i.e. by setting the new sysctl to 1.
2, accept until accept(2) returns -1. While on BSD, the situation is better, since kevent.data is used (epoll does not have this). The behavior is fixed by this commit.
Well, one man’s meat could be another man’s poison.
Isn’t this more an issue of NGINX using edge-triggered polling? If they used level-triggered polling they could more easily limit the amount of work they perform during each iteration of the event loop.
This is one reason why I’ve always avoided edge-triggered polling. The other reason being the difficulty of tracking down bugs, especially in non-core code, that didn’t reset the edge trigger. It never seemed worked the marginal (low single digits) gain in throughput.