Socket Sharding in Nginx Release 1.9.1
1–10 of 14 posts
Re: Socket Sharding in Nginx Release 1.9.1
#2I was under the impression the `SO_REUSEPORT` implementation on Linux was rather broken, as evidenced by HAProxy's graceful reload still dropping packets[1]. I'm curious as to why Nginx has implemented this when you can design your Nginx config around the problem while not encountering the broken implementation.
[1] http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
Re: Socket Sharding in Nginx Release 1.9.1
#3I was under the impression the `SO_REUSEPORT` implementation on Linux was rather broken, as evidenced by HAProxy's graceful reload still dropping packets[1]. I'm curious as to why Nginx has implemented this when you can design your Nginx config around the problem while not encountering the broken implementation. [1] http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
One of the contributors of REUSEPORT support is a long time Dragonfly BSD developer. No broken Linux implementation there.
Re: Socket Sharding in Nginx Release 1.9.1
#4I was under the impression the `SO_REUSEPORT` implementation on Linux was rather broken, as evidenced by HAProxy's graceful reload still dropping packets[1]. I'm curious as to why Nginx has implemented this when you can design your Nginx config around the problem while not encountering the broken implementation. [1] http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
One of the contributors of REUSEPORT support is a long time Dragonfly BSD developer. No broken Linux implementation there.
How does that help?
Re: Socket Sharding in Nginx Release 1.9.1
#5I was under the impression the `SO_REUSEPORT` implementation on Linux was rather broken, as evidenced by HAProxy's graceful reload still dropping packets[1]. I'm curious as to why Nginx has implemented this when you can design your Nginx config around the problem while not encountering the broken implementation. [1] http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
The issue that HAProxy is encountering with SO_REUSEPORT is not an issue for Nginx's use case.
In the HAProxy case one of the sockets belongs to the old server which is going away, and a new connection can be assigned to that socket right before it does so. For Nginx, all of the sockets are accepting new connections.
Re: Socket Sharding in Nginx Release 1.9.1
#6Re: Socket Sharding in Nginx Release 1.9.1
#7I was under the impression the `SO_REUSEPORT` implementation on Linux was rather broken, as evidenced by HAProxy's graceful reload still dropping packets[1]. I'm curious as to why Nginx has implemented this when you can design your Nginx config around the problem while not encountering the broken implementation. [1] http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...
The issue that HAProxy is encountering with SO_REUSEPORT is not an issue for Nginx's use case. In the HAProxy case one of the sockets belongs to the old server which is going away, and a new connection can be assigned to that socket right before it does so. For Nginx, all of the sockets are accepting new connections.
What happens during the reload case for nginx? At reload time, the previous-generation worker that bound to the socket with SO_REUSEPORT will need to close its listener, just like haproxy.
Re: Socket Sharding in Nginx Release 1.9.1
#8Earlier quoted context omitted.
The issue that HAProxy is encountering with SO_REUSEPORT is not an issue for Nginx's use case. In the HAProxy case one of the sockets belongs to the old server which is going away, and a new connection can be assigned to that socket right before it does so. For Nginx, all of the sockets are accepting new connections.
What happens during the reload case for nginx? At reload time, the previous-generation worker that bound to the socket with SO_REUSEPORT will need to close its listener, just like haproxy.
In nginx worker processes don't open and don't close sockets. They inherit them from the master process.
Re: Socket Sharding in Nginx Release 1.9.1
#9Earlier quoted context omitted.
The issue that HAProxy is encountering with SO_REUSEPORT is not an issue for Nginx's use case. In the HAProxy case one of the sockets belongs to the old server which is going away, and a new connection can be assigned to that socket right before it does so. For Nginx, all of the sockets are accepting new connections.
What happens during the reload case for nginx? At reload time, the previous-generation worker that bound to the socket with SO_REUSEPORT will need to close its listener, just like haproxy.
When reloading, nginx starts up a new set of workers and duplicates the sockets across to them with SCM_RIGHTS. None of the sockets is closed - only duplicate file descriptors.
Re: Socket Sharding in Nginx Release 1.9.1
#10Earlier quoted context omitted.
One of the contributors of REUSEPORT support is a long time Dragonfly BSD developer. No broken Linux implementation there.
How does that help?
It makes the implementation interesting for Dragonfly, at least. So why not do it?
And if it's offloading some work onto the kernel, having a popular tool support it may push Linux developers to fix the support.