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

Nginx Unit

nginx.com

Post reply on HN
Print view View original

141–150 of 236 posts

Re: Nginx Unit

#141

Post by pas »

kogepathic wrote: post #88
fermigier wrote: post #68

Earlier quoted context omitted.

Same. I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). A properly edited book would be awesome. I would pay for it of course.

> I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). uWSGI definitely needs more concise tutorials on how to accomplish some tasks (e.g. creating Hello World with python and uWSGI, or how the uWSGI emperor works). However I disagree with "lacking severely in the department of documentation" Sure,…

https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.h... it seems very quick and straight to the point (yet complete, it even starts with apt-get)

https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html - has config snippets too

Or maybe you mean detailed step by step instructions, a'la howtoforge?

Re: Nginx Unit

#142

Post by vertex-four »

pilif wrote: post #27

> It is not recommended to expose unsecure Unit API why do people always use "not recommended" when they actually mean "do not ever do this or you'll end up the laughing stock in the tech press" Exposing this otherwise awesome API to the public will amount to a free RCE for everybody. So not ever expose this to the public, not even behind some authentication. It's very cool that by design it's only listening on a dom…

Technically, NOT RECOMMENDED is the same as SHOULD NOT in RFC2119 - i.e. "the full implications should be understood and the case carefully weighed before implementing any behavior described with this label". Not that this document uses those definitions, but.

Re: Nginx Unit

#143

Post by anonacct37 »

jimjag wrote: post #124

I am biased, but call me underwhelmed. It seems that with every "new" feature, nginx is copying Apache httpd, even now claiming to be the "swiss army knife" of web-servers. Embedded languages. Dynamic modules. Support of uWSGI. gracefull restarts. Thread pools... and yet people eat it up. Just goes to show what having corporate-backed marketing and PR can do.

I agree. Apache has great module support. I think their worst sin was that their debian package defaulted to a small number of workers and using a forking mpm leading people to believe apache was slow.

Their eventing/threaded mpm is basically nginx.

And now nignx is starting to gain the features of apache.

Re: Nginx Unit

#144

Post by doozy »

bkeroack wrote: post #128

It's worth noting that it's rarely necessary or desirable to put an app server like nginx in front of Go HTTP server applications. The Go standard library http and TLS stack are production quality and rock solid. Putting something in front is mostly cargo culting from people more used to the worlds of PHP/Python/Ruby/etc.

It's useful to put Varnish in front of the app server for caching and to serve static content from a separate process (and domain) running a light/tiny httpd server instead of Apache/Nginx

I don't use Go, but D (dlang), vibe.d, varnish and lighttpd are working real well for my latest venture.

Re: Nginx Unit

#145

Post by overcast »

Prefinem wrote: post #139
overcast wrote: post #132

Earlier quoted context omitted.

I never found Nginx especially simple to setup, the config files were always messy. Caddy seems to have knocked this out of the park for me, especially considering automated https, and redirection.

I use Caddy on all my small projects right now. I haven't used it long enough to install enough faith for production sized systems yet, but hopefully I will get there because it is much easier to setup. Still, nginx is a breeze compared to apache IMO

Been pretty rock solid for everything I've put on it! Side projects + corporate.

Re: Nginx Unit

#146

Post by ekimekim »

vertex-four wrote: post #138
scott_karana wrote: post #135

Earlier quoted context omitted.

Does the Go http library asynchronously serve static files, by default? Or is it going to block on any app requests? Nginx is extremely fast for that case, which is typically the reason most people proxy languages through it. ;-)

Go I/O is async by default, I figured, so... It could be that nginx is more efficient at static file serving, but that'd be down to being specifically designed and optimised for it rather than some "sync vs async" thing.

Minor quibble, in the context of serving static files (ie. from disk), go doesn't use async I/O, the file I/O blocks the thread until it's complete. But since go's scheduler is M:N this doesn't lock up the whole program, so your point stands.

Re: Nginx Unit

#147

Post by Prefinem »

overcast wrote: post #145
Prefinem wrote: post #139

Earlier quoted context omitted.

I use Caddy on all my small projects right now. I haven't used it long enough to install enough faith for production sized systems yet, but hopefully I will get there because it is much easier to setup. Still, nginx is a breeze compared to apache IMO

Been pretty rock solid for everything I've put on it! Side projects + corporate.

I will keep that in mind. You mind me asking what's your most complex setup and your scale?

Re: Nginx Unit

#148

Post by pas »

oelmekki wrote: post #50

I initially thought it would allow to dynamically handle upstreams list (and other configuration) like hipache is doing [1], which would be awesome for dokku or other container management systems which rely on system nginx. But after seeing languages mentioned, I'm confused. Is it supposed to replace language specific servers, like unicorn and puma for rails (but then, I'm confused about what such kind of support wou…

Kong would be ideal in front of dokku: https://getkong.org

It works with postgres or cassandra (and eventually scylladb https://github.com/Mashape/kong/issues/754 ).

Also, nginx is pretty good at restarts, even with thousands of files and vhosts.

Re: Nginx Unit

#149

Post by kogepathic »

pas wrote: post #141
kogepathic wrote: post #88

Earlier quoted context omitted.

> I really want to like (and use) uWSGI, for many reasons, but I find it's lacking severely in the department of documentation (searching "uwsgi" on Amazon gives zero hits!). uWSGI definitely needs more concise tutorials on how to accomplish some tasks (e.g. creating Hello World with python and uWSGI, or how the uWSGI emperor works). However I disagree with "lacking severely in the department of documentation" Sure,…

https://uwsgi-docs.readthedocs.io/en/latest/WSGIquickstart.h... it seems very quick and straight to the point (yet complete, it even starts with apt-get) https://uwsgi-docs.readthedocs.io/en/latest/Emperor.html - has config snippets too Or maybe you mean detailed step by step instructions, a'la howtoforge?

> Or maybe you mean detailed step by step instructions, a'la howtoforge?

Yes, this is what I meant when I said

> IMHO the documentation is not lacking, it's just not forthcoming.

Re: Nginx Unit

#150

Post by wyc »

bkeroack wrote: post #128

It's worth noting that it's rarely necessary or desirable to put an app server like nginx in front of Go HTTP server applications. The Go standard library http and TLS stack are production quality and rock solid. Putting something in front is mostly cargo culting from people more used to the worlds of PHP/Python/Ruby/etc.

Pushing back on this a bit...for example, securely exposing a JSON endpoint to the public internet requires extra machinery that applications like nginx bring for free. If you simply set the router to your handler, then you accept arbitrarily large request sizes, wide open for DoS attacks. You have to either manually add limits or pull in some library. nginx caps these by default. Want throttling or load balancing? Again, things that haproxy and nginx do well, but require more cruft in your application.
Post reply on HN