4 ms·

nginx can reload the config files without closing the listening port or interrupting any existing requests. haproxy can't do that. So you can actually live-upda

by ploxiln 10y ago

nginx can reload the config files without closing the listening port or interrupting any existing requests. haproxy can't do that. So you can actually live-update on-demand much more of the nginx configuration than you can the haproxy configuration.

paulddraper 10y ago
> haproxy can't do that. HAProxy reloads don't interrupt existing connections (unless you want it to). There is a ~microsecond downtime in accepting new connections. https://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html https://engineeringblog.yelp.com/2015/04/true-zero-downtime-...
jbergstroem 10y ago
Logging in to machines to update configs doesn't scale well. You often end up building your own framework/api "only" to edit the config file. Or paying $2500/instance/year for nginx plus.
- ploxiln 10y ago
  Executing a template, writing it to a file, and sending SIGHUP, is not that hugely different from composing a request and writing it to a control socket. Maybe nginx isn't better than haproxy for many purposes. But updating configuration isn't the reason :)
- deckiedan 10y ago
  Ansible is working great for me.
- vacri 10y ago
  If that's a problem for you, then use a pull-style config management tool (eg puppet) over a push-style one (eg ansible). If you're at a scale where logging into each server from your control node 'hurts', then you're still going to hurt with all the config other than nginx anyway.
- deleted 10y ago
  [deleted]
onestone 10y ago
This doesn't work well for modern websites using push-style updates, e.g. via websockets. Old nginx processes might never close after the reload, as connections are very long-lived. If reloads happen often this leads to memory exhaustion. So this is a bad solution to rely on.
- ploxiln 10y ago
  Websockets are indeed a complication, I'm guessing for haproxy also. But it seems nginx has a recently added feature which can fix this: https://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout https://nginx.org/en/docs/ngx_core_module.html#worker_shutdo...

by ploxiln 10y ago

paulddraper 10y ago

> haproxy can't do that. HAProxy reloads don't interrupt existing connections (unless you want it to). There is a ~microsecond downtime in accepting new connections. https://engineeringblog.yelp.com/2015/04/true-zero-downtime-haproxy-reloads.html https://engineeringblog.yelp.com/2015/04/true-zero-downtime-...

jbergstroem 10y ago

Logging in to machines to update configs doesn't scale well. You often end up building your own framework/api "only" to edit the config file. Or paying $2500/instance/year for nginx plus.

ploxiln 10y ago
Executing a template, writing it to a file, and sending SIGHUP, is not that hugely different from composing a request and writing it to a control socket. Maybe nginx isn't better than haproxy for many purposes. But updating configuration isn't the reason :)
deckiedan 10y ago
Ansible is working great for me.
vacri 10y ago
If that's a problem for you, then use a pull-style config management tool (eg puppet) over a push-style one (eg ansible). If you're at a scale where logging into each server from your control node 'hurts', then you're still going to hurt with all the config other than nginx anyway.
deleted 10y ago
[deleted]

onestone 10y ago

This doesn't work well for modern websites using push-style updates, e.g. via websockets. Old nginx processes might never close after the reload, as connections are very long-lived. If reloads happen often this leads to memory exhaustion. So this is a bad solution to rely on.

ploxiln 10y ago
Websockets are indeed a complication, I'm guessing for haproxy also. But it seems nginx has a recently added feature which can fix this: https://nginx.org/en/docs/ngx_core_module.html#worker_shutdown_timeout https://nginx.org/en/docs/ngx_core_module.html#worker_shutdo...