关于例如 gin 之类的使用 net/http 框架，如何通过接口响应时间预估理想下的承载量。

@don178 ….

这是 gin 底层，也就是 net/http 监听端口相关操作。我要是控制任务数量肯定是从这方面下手，肯定不是从判断协程数量趣处理。db,job,很多东西都有可能增加 goroutinue 的数量。我如果要控制http的work数量要准确控制同一时间处理http请求的。
你说的那个方案我还不如从中间件计数，来一个加一，执行完毕减一。但是这并不能阻止 goroutinue 数量的增加。 如果并非调用 net/http ,而是魔改这个库/或者自定义一个http底层库判断当前的链接数量进而排队确实可以实现来处理。不过是疑问大家用 基于 net/http 的框架开发时有没有控制这个数量。或者在前一层 ng 上对客户端的链接做处理，超过多的就进行排队，没有到达 go service 。因为大家开发 无论是 gin还是iris之类的底层都是 net/http , 基于fasthttp的还是比较少，类似 fibber 这种的还有一些小bug。 用 net/http 底层确实是无限goroutinue 。疑问是这个地方会不会有问题

for {
        rw, err := l.Accept()
        if err != nil {
            select {
            case <-srv.getDoneChan():
                return ErrServerClosed
            default:
            }
            if ne, ok := err.(net.Error); ok && ne.Temporary() {
                if tempDelay == 0 {
                    tempDelay = 5 * time.Millisecond
                } else {
                    tempDelay *= 2
                }
                if max := 1 * time.Second; tempDelay > max {
                    tempDelay = max
                }
                srv.logf("http: Accept error: %v; retrying in %v", err, tempDelay)
                time.Sleep(tempDelay)
                continue
            }
            return err
        }
        connCtx := ctx
        if cc := srv.ConnContext; cc != nil {
            connCtx = cc(connCtx, rw)
            if connCtx == nil {
                panic("ConnContext returned nil")
            }
        }
        tempDelay = 0
        c := srv.newConn(rw)
        c.setState(c.rwc, StateNew, runHooks) // before Serve can return
        go c.serve(connCtx)
    }

控制数量这方面，你可以换个思路，不一定非要阻止goroutinue的新增，可以在达到一定数量后，对再次新增的goroutinue快速关闭，或者直接执行exit。http链接数我认为并不能代表goroutinue数量，根本没法得知这个链接处理需要使用多少goroutinue。其实并没有必要计数出http goroutinue的数量，有gmp数量多了goroutinue自动进入等待队列。