Go and Apache

721 views
Skip to first unread message

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
        RewriteRule ^(.*)$ http://localhost:8080/$1 [P,L]
    </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.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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
As fastcgi in go haven't been optimized yet, it's slower then http: https://gist.github.com/hgfischer/7965620

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

On Monday, February 8, 2016 at 5:19:36 PM UTC+1, Tamás Gulácsi wrote:
> As fastcgi in go haven't been optimized yet, it's slower then http: https://gist.github.com/hgfischer/7965620

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!
Reply all
Reply to author
Forward
0 new messages