Go（lang）app：nginx反向代理VS nginx主机

Question

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

Answer 1

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.

Answer 2

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.