Thank you for your great job on gin framework, I do like and learned a lot from it!

As we know, the standard library serve each connection with a goroutine. In high concurrency scenarios, it makes lots of goroutines and costs that much memory.

But using non-blocking frameworks, it enables us to greatly reduce the number of goroutines in high concurrency scenarios, thereby reducing the corresponding memory usage and cpu scheduling cost.

So I wrote nbio, which is a non-blocking networking framework, and implement HTTP1.x-Parser and HTTP-Server on it, Websocket and Http2.0 is in plan.

And it is compatible with the http.Handler of the standard library, so most web frameworks based on the standard library can easily use it as a network layer.

See this example for gin, and test with 10k or even up to 100k connections, then check the number of goroutines, memory usage and cpu or other cost of this server :

package main

import (
    "fmt"
    "net/http"
    "runtime"
    "sync/atomic"
    "time"

    "github.com/gin-gonic/gin"
    "github.com/lesismal/nbio/nbhttp"
)

func main() {
    var (
        qps   uint64 = 0
        total uint64 = 0
    )

    router := gin.New()
    router.GET("/hello", func(c *gin.Context) {
        atomic.AddUint64(&qps, 1)
        c.String(http.StatusOK, "hello")
    })

    svr := nbhttp.NewServer(nbhttp.Config{
        Network:      "tcp",
        Addrs:        []string{"localhost:8080"},
    }, router, nil, nil)

    err := svr.Start()
    if err != nil {
        fmt.Printf("nbio.Start failed: %v\n", err)
        return
    }
    defer svr.Stop()

    ticker := time.NewTicker(time.Second)
    for i := 1; true; i++ {
        <-ticker.C
        n := atomic.SwapUint64(&qps, 0)
        total += n
        fmt.Printf("running for %v seconds, online: %v, NumGoroutine: %v, qps: %v, total: %v\n", i, svr.State().Online, runtime.NumGoroutine(), n, total)
    }
}

test with 10k connections using wrk

wrk -t4 -c10000 -d30s --latency http://localhost:8080/hello

Compared with the standard library, it can greatly improve the load capacity of the hardware of the same configuration.

So, whether it is suitable to support non-blocking networking layer inside the gin framework using nbio or other framework?

Comment From: takanuva15

Hi, why did you close this issue? Does gin have support for non-blocking APIs yet?

Comment From: lesismal

It seems nobody care about it