Scaling webscocket connections using golang

func handleConn(w http.ResponseWriter, r *http.Request) {
        ws, err := upgrader.Upgrade(w, r, nil)
        if err != nil {
            if _, ok := err.(websocket.HandshakeError); !ok {
                log.Println(err)
            }
            return
       }

        go writer(ws)
        reader(r, ws)
    }

    func main() {
       http.HandleFunc("/", handleConn)
    }

I am trying to build a high scaling websocket server using golang. Since there is lack of support in native go websocket package, i am using https://github.com/gorilla/websocket.

For every connection, a goroutine will be spawned to take care of writes to it. For scaling huge number of connections. Let’s say if I have 1M concurrent connections then there should be 1M goroutines will be running on the server.

Hardware Specification:

16 GB Ram

4 Core CPU

2.5 GHz Intel Core i5

will it work for large number of connections without affecting the performance?

Looks like you’ll have at least 2M goroutines - each connection will have one for handleConn() and one for writer().

You may need some Linux Kernel tuning among other things.

A relevant post about making 10mill concurrent connections - http://goroutines.com/10m

I’d say this depends primarily on how much load each goroutine creates, in terms of CPU load, memory usage, and I/O throughput (among other things).

A potential issue that you might have is open file descriptors, per user/process. There are two major limit values hard and soft. I believe hard is defined by the kernel based on your hardware(Correction if incorrect please) and soft is software defined. So I would really look into that, seems like @sairam’s link goes over ways to set this value to the proper limit. I had issues with it recently when stress testing an application that didn’t have any rate limiting on it.

I would also suggest a simple channel that will lock until there is a process available(In your case that number would be 1M). Otherwise you’re going to run into FD issues after passing your FD limits.

Of course with all of this you might still run into performance issues based around your actual hardware, but first write the scalable code and see where it goes for the stress test.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.