3

I have already read some of the questions about go and nginx but I didn't find any answer to my one.

I think (i'm not an expert) that using nginx as a reverse proxy in front of a net/http go server is different as directly hosting your go application with nginx.
Shout at me if I'm wrong, ok?

The question came to me because I need to develop an application (possibly with go, just to learn something new) and have total control on the webserver, especially on the number of workers it uses to answer requests.

So, here come the questions:

  1. Is it possible to directly host a go app on nginx, or is it nginx that only serves static files (if the answer is "NO", then the second question doesn't make much sense)?

  2. What are the key differences between the two approaches above, precisely, does the different approaches affects the configuration someway?

  3. I am scared about telling nginx: "Ok, use 8 workers, please" and telling nothing to go's internal webserver... What would happen?

Thank you so much in advance

Community
  • 1
  • 1
affo
  • 453
  • 3
  • 15
  • 2
    There's no such thing as "directly hosting a go application with nginx". – JimB Oct 14 '15 at 13:43
  • I'm not sure what you mean by "Host a go app on nginx." nginx is a webserver and your app (by definition) is an application. The common thing to do is to have your app listen on a local port (let's say 4040) and set nginx up in front of it to reverse proxy from remote port 80 to local port 4040 so that your app handles the request. – Adam Smith Oct 14 '15 at 13:44
  • Similarly telling nginx to use 8 workers means there's 8 worker threads available to handle JUST THE reverse proxy requests. If you're getting a lot of requests at once that might be helpful, but since nginx is just serving (pun intended) as a signpost here, it's probably unnecessary. Golang's workers are entirely separate from nginx's. – Adam Smith Oct 14 '15 at 13:46

2 Answers2

5

Herbert Fischer wrote a comprehensive benchmark of Nginx with Go, including NGinx configuration files and Go code.

He checked the following settings:

  • Go HTTP standalone (as the control group)
  • Nginx proxy to Go HTTP
  • Nginx fastcgi to Go TCP FastCGI
  • Nginx fastcgi to Go Unix Socket FastCGI

Nginx proxy to Go HTTP was, by far, the fastest. The results were pretty much the same in Go versions since 1.2.

Adam Matan
  • 128,757
  • 147
  • 397
  • 562
3

Is it possible to directly host a go app on nginx

Nginx can communicate with its backend (your app) through various different mechanisms. Some of them are:

  • Via CGI/FastCGI (process multiplexing)
  • Via HTTP (reverse proxying)
  • Serving static files which your app produced

does the different approaches affects the configuration someway?

Yes, each case is very different.

Ok, use 8 workers, please

That would suggest FastCGI, which I believe is what you mean when you say "directly hosting an application on nginx".

telling nothing to go's internal webserver... What would happen?

Each Go FastCGI process would spawn a lot of goroutines, which are multiplexed to software threads, which are multiplexed to hardware threads, which are multiplexed to CPU cores.

Go's net/http server is good enough for a production environment, you don't necessarily need nginx unless you want to use some nginx-specific feature. There are only so many use cases where a FastCGI setup makes sense. You just add overhead, basically.

thwd
  • 23,956
  • 8
  • 74
  • 108
  • 2
    Also note that FastCGI is a pre-http/1.1 relic. Go's http/1.1 server is far faster and more efficient than the fcgi implementation. – JimB Oct 14 '15 at 14:21
  • Perfect. I think I was misunderstanding the relationship web/application server. The first bullet list someway cleared my mind. Can you please rephrase "That would suggest FastCGI, which I believe..."? Did you mean "That would affect..."? Thank you – affo Oct 14 '15 at 15:35
  • I think there was some confusion between nginx workers (which are independant of whatever backend you're using) and FastCGI workers, which aren't related. The worker count you set in nginx is entirely dependent on your hardware and performance requirements, but having multiple nginx workers proxying to one Go backend is *not* a problem (it "just works"). – elithrar Oct 14 '15 at 23:47
  • My consideration is another one. I'll try to explain better: Say you have nginx and a nodejs backend. Node is single threaded and will use a thread at a time to process requests. Now, if I tell nginx "Use 8 workers" I think it is not a great deal. I will need to spawn 8 backends and load-balance them with nginx to achieve what I meant telling nginx "Use 8 workers". Is it clearer? – affo Oct 15 '15 at 10:14