-2

I am learning source code about golang , at the source code create new connection for each request in net/http, like:

// Create new connection from rwc.
func (srv *Server) newConn(rwc net.Conn) (c *conn, err error) {
    c = new(conn)
    c.remoteAddr = rwc.RemoteAddr().String()
    c.server = srv
    c.rwc = rwc
    c.w = rwc
    if debugServerConnections {
        c.rwc = newLoggingConn("server", c.rwc)
    }
    c.sr.r = c.rwc
    c.lr = io.LimitReader(&c.sr, noLimit).(*io.LimitedReader)
    br := newBufioReader(c.lr)
    bw := newBufioWriterSize(checkConnErrorWriter{c}, 4<<10)
    c.buf = bufio.NewReadWriter(br, bw)
    return c, nil
}

why new(conn) at this place, is there can improve performance do with get conn from sync.Pool

sope
  • 1,619
  • 5
  • 19
  • 37
  • Should `sysn.Pool` be `sync.Pool`? – glyn Dec 04 '15 at 10:46
  • Sorry for wrong word, It is `sync.Pool`. – sope Dec 04 '15 at 10:50
  • 1
    The [`conn`](https://golang.org/src/net/http/server.go) struct is relatively small and holds configuration parameters/state, so the benefit of a re-usable pool isn't likely worth it for the tiny amount of garbage it generates. If this were a 4K buffer being thrown away every connection, then yes, a pool *may* (after benchmarking!) be useful. – elithrar Dec 04 '15 at 10:59
  • You actually read the source code. For this I gave you an upvote. Even if the concern smells like premature optimisation. Keep reading the source code. – thwd Dec 04 '15 at 13:56
  • 1
    The http server already has a pool in a sense, keepalive, which reuses the connections as often as possible. Plus, it's usually not worth the effort to zero out all the fields in a struct like this when the GC can do that for you more efficiently. – JimB Dec 04 '15 at 16:05

1 Answers1

0

Does this question stem from measuring performance of an application or simply, as the title implies, from reading the source code? The basic rule of performance optimisation is "measure, don't guess" (see, for example, this article).

Apart from performance, there may be a good reason for not using sync.Pool here. You would need to know at what point the connection is no longer used and can safely be put back in the pool.

That said, your suggestion may have some merit if it is obvious at what point(s) in the code the connection needs to be returned to the pool. Why not measure the performance improvement for a (realistic if small) application that could benefit? If there's a really significant benefit, it might be worth proposing to the Go community. However, the main benefit of sync.Pool is to reduce GC overhead, so the application would have to create many connections for there to be a noticeable benefit.

glyn
  • 1,180
  • 8
  • 19
  • Thanks for your hints. I am fresh with golang. It seem can know at what point the connection is no longer used from what I saw in the source code in `http/server.go` line 1365: `w.finishRequest()`, but I don`t know whether have really done. – sope Dec 04 '15 at 11:30
  • You're welcome. Reading the Go standard libraries is a good way to become familiar with idiomatic Go code. If you would like a good textbook on Go, I recommend ["D&K"](http://www.gopl.io/). The [Go Newsletter](http://golangweekly.com/) is worth subscribing to - regularly includes interesting articles and videos. – glyn Dec 04 '15 at 11:35
  • Yes, I have subscribed Go Newsletter. – sope Dec 04 '15 at 11:39