valyala / fasthttp

Fast HTTP package for Go. Tuned for high performance. Zero memory allocations in hot paths. Up to 10x faster than net/http
MIT License
21.66k stars 1.75k forks source link

question: cpu profiler shows many calls of fasthttp.(*workerPool).getCh.func1 #1384

Closed stokito closed 1 year ago

stokito commented 1 year ago

I would be thankful if you can help me. The CPU profile of my server under 12,000 QPS on 8(16) core shows this cpu profile

Only the last function is belong to my server itself. Internally it calls another server with fasthttp client.

Is this fine that most time is spent in this function? As far I understood count of gorotines is too high and most CPU is spent to wait for a new goroutine.

erikdubbelboer commented 1 year ago

getCh is called each time a new connection is opened. If that function itself is called very often it would indicate that you aren't using keep-alive connections and should really look into that.

stokito commented 1 year ago

thank you, you helped a lot. I added a logging when the connection is closed, and yes they are closed almost all. In the same time requests have the Connection: KeepAlive so this is a problem on senders side.

If anyone needs here is a sample hot to log connections:


   server := &fasthttp.Server{
    ConnState:                     serverConnState,
   }

func serverConnState(conn net.Conn, state fasthttp.ConnState) {
   if state == fasthttp.StateClosed || state == fasthttp.StateHijacked {
      log.Printf("conn: %s %s\n", state.String(), conn.RemoteAddr().String())
   }
}
Tristin-C commented 1 year ago

@stokito May I ask how your problem was solved

stokito commented 1 year ago

@Tristin-C I didn't fully solved the problem and switched to other tasks. We had one API client who didn't use the Keep Alive and we asked to fix it. Here I added a metric to count such requests without the Keep-Alive (or with Connection: close)

// Check that Keep Alive is used
if reqCtx.Request.Header.ConnectionClose() {
    MetricConn.WithLabelValues(clientId, "conn close").Inc()
}

Generally we added another one server and reduced load and now it behaves more or less fine but it's underloaded.

Tristin-C commented 1 year ago

@stokito Ok, thank you for your reply.