FAQ
I am working on a server program which (hopefully) needs to support a large
number of concurrent client connections. I am wondering if there is any
golang design pattern available which can be used to share workload between
multiple goroutines (probably via channels).

For example let's say if there are 1000 clients connected and sending
requests, is there any way to have 10 different goroutines split the work
load? A single channel handling the request to me seems single threaded.
Another option is to create one goroutine per client but it may not scale
well as number of connections grow. I am sort of looking for load balancing
goroutines.

I hope I have explained my questions well. Please let me know if you need
any clarification.

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

Search Discussions

  • András Pálinkás at Jun 16, 2015 at 2:14 am
    A single (buffered) channel and multiple goroutines receiving from that
    channel does exactly what you've described.
    On Saturday, June 13, 2015 at 4:07:11 PM UTC-4, Dipen Bhikadya wrote:

    I am working on a server program which (hopefully) needs to support a
    large number of concurrent client connections. I am wondering if there is
    any golang design pattern available which can be used to share workload
    between multiple goroutines (probably via channels).

    For example let's say if there are 1000 clients connected and sending
    requests, is there any way to have 10 different goroutines split the work
    load? A single channel handling the request to me seems single threaded.
    Another option is to create one goroutine per client but it may not scale
    well as number of connections grow. I am sort of looking for load balancing
    goroutines.

    I hope I have explained my questions well. Please let me know if you need
    any clarification.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dipen Bhikadya at Jun 16, 2015 at 2:36 am
    Makes sense. But how do you ensure that only one goroutine processes a
    request?
    On Jun 16, 2015 7:44 AM, "András Pálinkás" wrote:

    A single (buffered) channel and multiple goroutines receiving from that
    channel does exactly what you've described.
    On Saturday, June 13, 2015 at 4:07:11 PM UTC-4, Dipen Bhikadya wrote:

    I am working on a server program which (hopefully) needs to support a
    large number of concurrent client connections. I am wondering if there is
    any golang design pattern available which can be used to share workload
    between multiple goroutines (probably via channels).

    For example let's say if there are 1000 clients connected and sending
    requests, is there any way to have 10 different goroutines split the work
    load? A single channel handling the request to me seems single threaded.
    Another option is to create one goroutine per client but it may not scale
    well as number of connections grow. I am sort of looking for load balancing
    goroutines.

    I hope I have explained my questions well. Please let me know if you need
    any clarification.
    --
    You received this message because you are subscribed to a topic in the
    Google Groups "golang-nuts" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/golang-nuts/ZtmMZPijiek/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrewchamberss at Jun 16, 2015 at 2:36 am
    Go is generally meant to be one goroutine per client. The runtime handles
    this efficiently, even to thousands of clients.

    If you want to put an upper limit, you could simply refuse connections when
    you have reached the limit. At that point, you would multiple servers and a
    load balancer.
    On Sunday, June 14, 2015 at 8:07:11 AM UTC+12, Dipen Bhikadya wrote:

    I am working on a server program which (hopefully) needs to support a
    large number of concurrent client connections. I am wondering if there is
    any golang design pattern available which can be used to share workload
    between multiple goroutines (probably via channels).

    For example let's say if there are 1000 clients connected and sending
    requests, is there any way to have 10 different goroutines split the work
    load? A single channel handling the request to me seems single threaded.
    Another option is to create one goroutine per client but it may not scale
    well as number of connections grow. I am sort of looking for load balancing
    goroutines.

    I hope I have explained my questions well. Please let me know if you need
    any clarification.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dipen Bhikadya at Jun 16, 2015 at 3:15 am
    One goroutine per client may be a good idea for getting requests and
    sending responses which I intend to do. However for request processing I am
    not sure goroutine per client can work. There would be too much congestion
    for "shared" work. I think having a limited set of goroutine sharing the
    workload is probably a better option. I am not sure though.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Yongjian Xu at Jun 16, 2015 at 3:49 am
    bound your incoming requests should just do your needs right? your main
    dispatcher loop could be something like a select loop with one channel
    sending accepted incoming requests and another sending a signal saying 'I
    am full, please go away' when the the request channel buffer is filled up
    (since that will block and make your signal channel go through). Say, if
    you have a buffer of 1000, then that would be your max concurrent capacity
    per server, above that would be all denied. For the rest of things, you
    don't have to worry too much, e.g. how many worker goroutines to handle the
    requests... just let the runtime handles that. To get a practical upper
    limit of your buffer limit, you should probably do some load test and make
    sure your storage system can handle them.
    On Mon, Jun 15, 2015 at 8:15 PM Dipen Bhikadya wrote:

    One goroutine per client may be a good idea for getting requests and
    sending responses which I intend to do. However for request processing I am
    not sure goroutine per client can work. There would be too much congestion
    for "shared" work. I think having a limited set of goroutine sharing the
    workload is probably a better option. I am not sure though.

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dipen Bhikadya at Jun 16, 2015 at 5:11 am
    You are right. I am probably overthinking in terms of number of goroutines
    etc. The reason I was thinking about worker goroutines/channels is because
    I have a global register where all connected clients have to be registered
    first and verified against for each request. I know global variables are
    anti-go recommendation and that's why I was trying to funnel requests
    through a few channels executing requests in parallel (with a register in
    each channel handler). That way the whole world doesn't to lock/unlock a
    single register. I guess I may have to revisit my application flow to let
    each request run in it's own goroutine.
    On Tuesday, June 16, 2015 at 9:19:29 AM UTC+5:30, i3dmaster wrote:

    bound your incoming requests should just do your needs right? your main
    dispatcher loop could be something like a select loop with one channel
    sending accepted incoming requests and another sending a signal saying 'I
    am full, please go away' when the the request channel buffer is filled up
    (since that will block and make your signal channel go through). Say, if
    you have a buffer of 1000, then that would be your max concurrent capacity
    per server, above that would be all denied. For the rest of things, you
    don't have to worry too much, e.g. how many worker goroutines to handle the
    requests... just let the runtime handles that. To get a practical upper
    limit of your buffer limit, you should probably do some load test and make
    sure your storage system can handle them.

    On Mon, Jun 15, 2015 at 8:15 PM Dipen Bhikadya <dipen.b...@gmail.com
    <javascript:>> wrote:
    One goroutine per client may be a good idea for getting requests and
    sending responses which I intend to do. However for request processing I am
    not sure goroutine per client can work. There would be too much congestion
    for "shared" work. I think having a limited set of goroutine sharing the
    workload is probably a better option. I am not sure though.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 13, '15 at 8:07p
activeJun 16, '15 at 5:11a
posts7
users4
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase