Go isn't detecting SOMAXCONN changes from aws ubuntu server

Question

I'm trying to stress test my golang net/http server with k6. When I'm using 2048 virtual users to hit my aws ubuntu server, k6 throws "connection reset by peer". Investigating on the internet, I found that probably the backlog queue is the problem. Reading some stackoverflow questions, I tried to modify SOMAXCONN variable from sysctl.conf file. After modifying it from 128 to 1024, when I run my main go program:

package main

import (
    "fmt"
    "log"
    "net/http"
    "strings"
    "golang.org/x/sys/unix"
)

func main() {
    http.HandleFunc("/some_path", handler)

    fmt.Println("SOMAXCONN:", unix.SOMAXCONN)
    log.Fatal(http.ListenAndServe(":8888", nil))
}

I have the following terminal output:

SOMAXCONN: 128

When in fact it should print:

SOMAXCONN: 1024

I'd appreciate if anyone can explain me why is GOLANG detecting 128 and not 1024.

`unix.SOMAXCONN` Is a constant, it’s not going to change – JimB Jan 20 '19 at 15:23 — JimB, Jan 20 '19 at 15:23

score 1 · Accepted Answer · answered Jan 20 '19 at 15:22

1

I would guess that the way you are checking the SOMAX is set when go is compiled?

Checking it in a different way by reading from /proc shows that net.core.somaxconn is altered

package main

import (
    "fmt"
    "log"
    "net/http"
    "os"
)

func main() {
    filename := "/proc/sys/net/core/somaxconn"
    f, err := os.Open(filename)
    data := make([]byte, 100)
    _, err2 := f.Read(data)
    if err != nil || err2 != nil {
        log.Println(err2)
        log.Fatal(err)
    }
    fmt.Printf("SOMAXCONN: %v", string(data))
    log.Fatal(http.ListenAndServe(":8888", nil))
}

answered Jan 20 '19 at 15:22

Vorsprung

32,923
5
39
63

When running your code, it prints the new value of somaxconn. What is interesting is that the http server performs worse than when somaxconn is on 128. Other thing is that now it throws Accept error: too many open files. Do you know if there is another variable that I have to modify in order to solve that problem? I believe that is something related with file descriptors, but not sure about it. – Joaco Terniro Jan 20 '19 at 15:49
you probably need to up the number of file descriptors as well as somax. Try seeing what fs.file-max is set to and increase that. Read up on it too. These parameters are set to low default for a reason, they use system resources – Vorsprung Jan 20 '19 at 15:53
I already tested different values of file descriptors (first I tried with only 100.000 and then setted 1.000.000). What I noticed was that, while increasing the amount o file descriptors, the error about Accept error: too many open files disappeared, but the response time increased a lot (reaching 2 seconds on TTFB). The final throughput reduced to half of the initial throughput, CPU usage didn't increase and also happened the same with memory usage. Any other suggestion to increase go net/http go server performance? Thanks for your support. – Joaco Terniro Jan 20 '19 at 16:46
increasing somaxconn probably will lead to increased response time see https://stackoverflow.com/questions/18073483/what-do-somaxconn-mean-in-c-socket-programming for a description of what the setting actually means. If the memory and cpu use on your server are constant and low then there is probably something you could do with the code to make it serve faster – Vorsprung Jan 20 '19 at 20:12

Go isn't detecting SOMAXCONN changes from aws ubuntu server

1 Answers1