FAQ
My team is implementing a websocket service using Go that uses the go.net
websocket library + the default http lib. At this point the vast majority
of the malloc's/GC pressure is due to the http lib and an occasional
websocket lib call. Also, since we want to implement max simultaneous
connections, the habit of spinning up the goroutine *before* checking to
see how many connections are present is causing some issues.

How open to a PR to fix these issues is the Go team? I would implement the
max simultaneous connections using an atomic counter such that new
goroutines to answer requests will not be spawned if an existing handler
has not completed the request. The max conn. could be set during the server
creation. Would that be ok?

The buffer issue is slightly different. In our benchmarks a substantial
amount of time is spent creating and recreating the buffers used to read
data from the http connection. If there was a max amount of connections I
would likely pre-allocate all the buffers and re-use them in a pool rather
than create new ones for every connection. We've done similar things for
our heka project which greatly relieved the GC pressure, and it seems like
that would help a lot with the http lib (if it was constrained up-front on
max conn's).

Is there some other easy answer to these problems I'm missing? Or does it
make sense to work on a PR and submit it?

Cheers,
Ben

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Brad Fitzpatrick at Aug 14, 2013 at 7:07 am
    It'd help to start with a benchmark, then analyze, then discuss. A pull
    request should be the last step.


    On Tue, Aug 13, 2013 at 7:34 PM, Ben Bangert wrote:

    My team is implementing a websocket service using Go that uses the go.netwebsocket library + the default http lib. At this point the vast majority
    of the malloc's/GC pressure is due to the http lib and an occasional
    websocket lib call. Also, since we want to implement max simultaneous
    connections, the habit of spinning up the goroutine *before* checking to
    see how many connections are present is causing some issues.

    How open to a PR to fix these issues is the Go team? I would implement the
    max simultaneous connections using an atomic counter such that new
    goroutines to answer requests will not be spawned if an existing handler
    has not completed the request. The max conn. could be set during the server
    creation. Would that be ok?

    The buffer issue is slightly different. In our benchmarks a substantial
    amount of time is spent creating and recreating the buffers used to read
    data from the http connection. If there was a max amount of connections I
    would likely pre-allocate all the buffers and re-use them in a pool rather
    than create new ones for every connection. We've done similar things for
    our heka project which greatly relieved the GC pressure, and it seems like
    that would help a lot with the http lib (if it was constrained up-front on
    max conn's).

    Is there some other easy answer to these problems I'm missing? Or does it
    make sense to work on a PR and submit it?

    Cheers,
    Ben

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kyle Lemons at Aug 14, 2013 at 8:47 am

    On Tue, Aug 13, 2013 at 7:34 PM, Ben Bangert wrote:

    My team is implementing a websocket service using Go that uses the go.netwebsocket library + the default http lib. At this point the vast majority
    of the malloc's/GC pressure is due to the http lib and an occasional
    websocket lib call. Also, since we want to implement max simultaneous
    connections, the habit of spinning up the goroutine *before* checking to
    see how many connections are present is causing some issues.

    How open to a PR to fix these issues is the Go team? I would implement the
    max simultaneous connections using an atomic counter such that new
    goroutines to answer requests will not be spawned if an existing handler
    has not completed the request. The max conn. could be set during the server
    creation. Would that be ok?
    It would already be possible to create a net.Listener/net.Conn combo which
    only allows a certain number of connections to be open at once. In
    general, though, I would consider this to be the purview of a loadbalancer
    and/or a frontend, and not a worker.

    The buffer issue is slightly different. In our benchmarks a substantial
    amount of time is spent creating and recreating the buffers used to read
    data from the http connection. If there was a max amount of connections I
    would likely pre-allocate all the buffers and re-use them in a pool rather
    than create new ones for every connection. We've done similar things for
    our heka project which greatly relieved the GC pressure, and it seems like
    that would help a lot with the http lib (if it was constrained up-front on
    max conn's).
    The Go http library already attempts to reuse buffers, though it only
    caches 4 of them. It has a TODO to use sync.Cache, so maybe that could
    become a field of the Server in the future that you can configure to your
    liking.

    Is there some other easy answer to these problems I'm missing? Or does it
    make sense to work on a PR and submit it?

    Cheers,
    Ben

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Pieter Droogendijk at Aug 14, 2013 at 11:11 am

    On Wednesday, 14 August 2013 10:47:29 UTC+2, Kyle Lemons wrote:
    The Go http library already attempts to reuse buffers, though it only
    caches 4 of them. It has a TODO to use sync.Cache, so maybe that could
    become a field of the Server in the future that you can configure to your
    liking.
    sync.Cache was axed, at least for now:
    https://groups.google.com/forum/#!msg/golang-dev/QtSIOFsNFrQ/2fIvUAin8DAJ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Gerrand at Aug 14, 2013 at 11:21 am

    On 14 Aug 2013 18:47, "Kyle Lemons" wrote:
    On Tue, Aug 13, 2013 at 7:34 PM, Ben Bangert wrote:

    My team is implementing a websocket service using Go that uses the go.netwebsocket library + the default http lib. At this point the vast majority
    of the malloc's/GC pressure is due to the http lib and an occasional
    websocket lib call. Also, since we want to implement max simultaneous
    connections, the habit of spinning up the goroutine *before* checking to
    see how many connections are present is causing some issues.
    How open to a PR to fix these issues is the Go team? I would implement
    the max simultaneous connections using an atomic counter such that new
    goroutines to answer requests will not be spawned if an existing handler
    has not completed the request. The max conn. could be set during the server
    creation. Would that be ok?

    https://codereview.appspot.com/12727043/
    It would already be possible to create a net.Listener/net.Conn combo
    which only allows a certain number of connections to be open at once. In
    general, though, I would consider this to be the purview of a loadbalancer
    and/or a frontend, and not a worker.
    The buffer issue is slightly different. In our benchmarks a substantial
    amount of time is spent creating and recreating the buffers used to read
    data from the http connection. If there was a max amount of connections I
    would likely pre-allocate all the buffers and re-use them in a pool rather
    than create new ones for every connection. We've done similar things for
    our heka project which greatly relieved the GC pressure, and it seems like
    that would help a lot with the http lib (if it was constrained up-front on
    max conn's).

    The Go http library already attempts to reuse buffers, though it only
    caches 4 of them. It has a TODO to use sync.Cache, so maybe that could
    become a field of the Server in the future that you can configure to your
    liking.
    Is there some other easy answer to these problems I'm missing? Or does
    it make sense to work on a PR and submit it?
    Cheers,
    Ben

    --

    ---
    You received this message because you are subscribed to the Google
    Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send
    an email to golang-dev+unsubscribe@googlegroups.com.

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedAug 14, '13 at 7:04a
activeAug 14, '13 at 11:21a
posts5
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase