Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx Unit – Universal web app server

github.com

Post reply on HN
Print view View original

151–160 of 201 posts

Re: Nginx Unit – Universal web app server

#151

Post by fragmede »

gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

> How often do you need to add php support on the fly?

Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Re: Nginx Unit – Universal web app server

#152

Post by 22c »

fragmede wrote: post #151
gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

> How often do you need to add php support on the fly? Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Although it doesn't directly go against what you're saying, many Unix daemons have supported HUP signals for decades which can achieve the same outcome. No need to configure via API, just change the configuration on disk and send HUP.

I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?

Re: Nginx Unit – Universal web app server

#153

Post by jen20 »

gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

Perhaps adding support for PHP on the fly is an extreme case, but reconfiguring eg load balancer backends when new systems come and go without having to render a config file and HUP (and hope) is a typical case.

Re: Nginx Unit – Universal web app server

#154

Post by otterley »

usrusr wrote: post #23

So much JSON... is that the real thing, as in comments are the gateway to hell, or is it actually some practical JSON superset like JSON5? I almost see myself jury-rigging some bespoke filesystem on-ramp to that REST configuration interface. Likely with at least half a dozen scary security compromises. Then on the other hand I guess they've never been afraid of getting called opinionated and that's certainly much bet…

I like to think of JSON as a low-level configuration language that most people should generate from a higher-level language such as Python or JSONnet — sort of like assembly is to C. JSON has lots of things to like about it, but I don’t recommend generating it manually for most people for files larger than a few lines.

Re: Nginx Unit – Universal web app server

#155

Post by hamandcheese »

fragmede wrote: post #151
gibmeat wrote: post #90

Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?

> How often do you need to add php support on the fly? Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Any half decent containerized setup should support zero-downtime deploys. Usually it involves bringing up new containers and signaling the existing containers to begin draining connections.

For most workloads it should be entirely possible to deploy a new stateless config and not need to resort to using mutable state for critical infrastructure.

If you have long-lived, stateful connections (perhaps for live streams) then I can see why re-configuring in place would be desirable, but in my experience that's pretty rare.

Re: Nginx Unit – Universal web app server

#156

Post by hamandcheese »

22c wrote: post #152
fragmede wrote: post #151

Earlier quoted context omitted.

> How often do you need to add php support on the fly? Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Although it doesn't directly go against what you're saying, many Unix daemons have supported HUP signals for decades which can achieve the same outcome. No need to configure via API, just change the configuration on disk and send HUP. I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?

To me this is identical - mutable state is mutable state, whether it starts on disk first makes no difference.

Re: Nginx Unit – Universal web app server

#157

Post by tiffanyh »

jchook wrote: post #83

Nginx Unit + PHP seems to handedly out-perform Nginx + php-fpm[1][2][3]. Also, Docker environments running PHP via Nginx Unit will no longer need separate containers for http + fpm, as it works similar to Apache's mod_php. 1. https://habr.com/en/articles/646397/ 2. https://medium.com/@le_moment_it/nginx-unit-discover-and-ben... 3. https://github.com/nginx/unit/issues/6#issuecomment-38407362...

Two questions:

1. Does Unit + PHP doing the typical “initialize & teardown” that PHP is know for?

Or is Unit persisting the initialization/setup, hence why it’s achieving the way faster results?

2. How is Unit/PHP architecturally different than NGX-PHP (an event loop)?

https://github.com/rryqszq4/ngx-php

Re: Nginx Unit – Universal web app server

#158

Post by notnmeyer »

shawabawa3 wrote: post #150
ramesh31 wrote: post #146

Earlier quoted context omitted.

>Why the obsession (it seems to be the prominent point in the readme) with configuration via API? Infrastructure As Code (in all its forms, chef/puppet/ansible/tfe etc.) is the standard for all enterprise cloud setups these days. It makes sense to support that as a first class feature.

but this is the opposite of infrastructure-as-code This is infrastructure-as-state You have to manage automatically loading configs and keeping in sync with what you have in code, instead of deploying with a static configuration file

it’s not hard to imagine a use case where there are backend configurations stored in a database somewhere and you want to apply them. i’m picturing it as data vs static configuration.

Re: Nginx Unit – Universal web app server

#159

Post by Dachande663 »

tiffanyh wrote: post #157
jchook wrote: post #83

Nginx Unit + PHP seems to handedly out-perform Nginx + php-fpm[1][2][3]. Also, Docker environments running PHP via Nginx Unit will no longer need separate containers for http + fpm, as it works similar to Apache's mod_php. 1. https://habr.com/en/articles/646397/ 2. https://medium.com/@le_moment_it/nginx-unit-discover-and-ben... 3. https://github.com/nginx/unit/issues/6#issuecomment-38407362...

Two questions: 1. Does Unit + PHP doing the typical “initialize & teardown” that PHP is know for? Or is Unit persisting the initialization/setup, hence why it’s achieving the way faster results? 2. How is Unit/PHP architecturally different than NGX-PHP (an event loop)? https://github.com/rryqszq4/ngx-php

PHP’s had an opcache and jit for several versions now. Combined with preload options, this means startup time is negligible.
Post reply on HN