Tomi Häsä
unread,
Feb 6, 2016, 12:55:32 PM2/6/16
to golang-nuts
I found a web page that tells how to make Go work with Apache, when you are using a virtual host file:
I can make a simple Go test server work *without* Apache, but I can't make the same test program work with Apache on CentOS 7 using Amazon EC2 instance.
So, I'm curious, what is the normal way of using Go with Apache? Do I need to move the Go program to cgi-bin folder or make changes to the Apache configuration files and what kind of changes? For me, it's surprisingly difficult to find a simple example for Go + Apache. ;)
I probably don't need this kind of file at /etc/httpd/sites-available/[mywebsite]:
#######################################################
<VirtualHost *:80>
ServerName [mywebsite]
ServerAlias [mywebsite]
DocumentRoot /var/www/[mywebsite]/public_html
# ErrorLog /var/www/[mywebsite]/error.log
# CustomLog /var/www/[mywebsite]/requests.log combined
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/[mywebsite]>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
RewriteEngine on
</Directory>
</VirtualHost>
#######################################################
The simple Go test server program:
// ****************************************************
package main
import (
"net/http"
"log"
)
const resp = `<html>
<head>
<title>Simple Web App</title>
</head>
<body>
<h1>Simple Web App</h1>
<p>Hello World!</p>
</body>
</html>`
func handler( w http.ResponseWriter,
r *http.Request ) {
w.Write([]byte(resp))
}
func main() {
http.HandleFunc( "/", handler )
err := http.ListenAndServe( ":8080", nil )
if err != nil {
log.Fatal( "ListenAndServe: ", err.Error() )
}
}
// ****************************************************
Michael Banzon
unread,
Feb 6, 2016, 1:44:48 PM2/6/16
to Tomi Häsä, golang-nuts
Normally I would run the Go-program and the Apache server on two different high-number ports (8000 and 8001 eg.) and then have Nginx proxy requests to them according to the requests URLs.
Andy Balholm
unread,
Feb 6, 2016, 2:14:11 PM2/6/16
to Michael Banzon, Tomi Häsä, golang-nuts
You could also have your Go program reverse-proxy to Apache.
Silvan Jegen
unread,
Feb 8, 2016, 11:09:59 AM2/8/16
to golang-nuts, tomi...@gmail.com
On Saturday, February 6, 2016 at 7:44:48 PM UTC+1, mbanzon wrote:
> Normally I would run the Go-program and the Apache server on two different high-number ports (8000 and 8001 eg.) and then > have Nginx proxy requests to them according to the requests URLs.
What I did is writing the Go program using fast-cgi (net/http/fcgi) and use nginx as the front-end HTTP server. The idea is that nginx should deal with the network because it's good at it while the application logic is written in Go.
I would be intersted in seeing how high the overhead of fast-cgi is when compared to running the application in Go and using the Go HTTP stack with it.
Tamás Gulácsi
unread,
Feb 8, 2016, 11:19:36 AM2/8/16
to golang-nuts
ben.davies...@gmail.com
unread,
Feb 8, 2016, 11:56:00 AM2/8/16
to golang-nuts
thats a shame, I really like the idea of isolating the networking HTTP stuff into a sub-system that is battle tested for that, leaving my go programs to focus on their role via fast-cgi. Does anyone know if there are plans to optimize the fast-cgi stuff?
Konstantin Khomoutov
unread,
Feb 8, 2016, 2:40:37 PM2/8/16
to ben.davies...@gmail.com, golang-nuts
On Mon, 8 Feb 2016 08:55:45 -0800 (PST)
ben.davies...@gmail.com wrote:
> thats a shame, I really like the idea of isolating the networking
> HTTP stuff into a sub-system that is battle tested for that, leaving
> my go programs to focus on their role via fast-cgi. Does anyone know
> if there are plans to optimize the fast-cgi stuff?
What's wrong with just proxying requests to URLs not referring to
static data to a backend application? I mean, did you open the FastCGI
spec? Sure the transport it defines differs from HTTP but how does that
really matter when it comes to channeling the client's request to your
application and channeling its response back? The fact NGINX will
speak HTTP and not FastCGI when talking with your backend application
should IMO not somehow kill its ability to handle slow clients and do
other advanced kinds of stuff.
James Bardin
unread,
Feb 8, 2016, 3:05:24 PM2/8/16
to golang-nuts, ben.davies...@gmail.com
On Monday, February 8, 2016 at 11:56:00 AM UTC-5, ben.davies...@gmail.com wrote:
thats a shame, I really like the idea of isolating the networking HTTP stuff into a sub-system that is battle tested for that, leaving my go programs to focus on their role via fast-cgi. Does anyone know if there are plans to optimize the fast-cgi stuff?
The FastCGI spec is mostly a relic of the pre-HTTP/1.1 world. There's not a lot of use for FastCGI when compared to an HTTP/1.1 reverse proxy, so there's very little use of the package, hence no demand for optimization.
Brad Fitzpatrick
unread,
Feb 8, 2016, 6:44:57 PM2/8/16
to ben.davies...@gmail.com, golang-nuts
Go's networking and http are pretty good.
Apache is less magical than it was in the 90's.
I would give Go a shot. I personally trust putting a memory-safe, bounds-checked language facing the internet, instead of C.
Andy Balholm
unread,
Feb 8, 2016, 7:07:48 PM2/8/16
to Brad Fitzpatrick, ben.davies...@gmail.com, golang-nuts
I recently replaced nginx on my server with a Go program that is about the same length as the nginx configuration file.
Silvan Jegen
unread,
Feb 9, 2016, 4:27:22 AM2/9/16
to golang-nuts
That is exactly what I wanted, thanks! To summarize, for requests/s in the "GOMAXPROCS = 8" case and Nginx, FastCGI over a Unix socket is four time slower than using Go as an HTTP server directly. Nginx as a reverse proxy to a Go HTTP server is still only 58% of the speed of using Go HTTP directly.
I was expecting FastCGI to be faster since there is no HTTP overhead compared to the reverse proxy case. The differences are also much larger than I expected. Good to know for the next time!