net/http and the GC

[B Carr]

Gophers -

Trying to learn Go (I'm a hobbyist) and have a fundamental net/http question. I have a web server running with a web page set to refresh every 2 seconds. I have 3 different browsers making webserver GET requests. Each browser's refresh is spinning up a new goroutine on the server, right? And that leaves the preceding goroutine started by that browser's GET dead/unused going forward, right?

I'm watching the memory usage of the webserver and it is steadily increasing though it does seem to level off after a while.

Is the GC taking care of removing the unused goroutines and that is why I'm seeing the memory use increases start to level off? If I stop all the browsers would the GC gobble up all the now-useless goroutines and memory use for the webserver would drop back to nominal? At one point when I was tracking down one race condition (out of 839 reported), the race output showed "goroutine #29316". Good grief! I fixed all the race conditions reported.

If I set the page refreshes to a larger number, such as 5 minutes, would the GC gobble up the unused goroutines fast enough that I wouldn't see much increase in memory use?

Or am I thinking about this all wrong?

TIA,

Bucky

[Burak Serdar]

On Mon, Jul 8, 2019 at 9:30 AM B Carr <buc...@gmail.com> wrote:
>
> Gophers -
>
> Trying to learn Go (I'm a hobbyist) and have a fundamental net/http question. I have a web server running with a web page set to refresh every 2 seconds. I have 3 different browsers making webserver GET requests. Each browser's refresh is spinning up a new goroutine on the server, right? And that leaves the preceding goroutine started by that browser's GET dead/unused going forward, right?

Each HTTP request is handled in its own goroutine. Once the request is
handled, that goroutine terminates. So if your HTTP handler eventually
returns, that goroutine will eventually terminate. They won't be left
"unused".

>
> I'm watching the memory usage of the webserver and it is steadily increasing though it does seem to level off after a while.
>
> Is the GC taking care of removing the unused goroutines and that is why I'm seeing the memory use increases start to level off? If I stop all the browsers would the GC gobble up all the now-useless goroutines and memory use for the webserver would drop back to nominal? At one point when I was tracking down one race condition (out of 839 reported), the race output showed "goroutine #29316". Good grief! I fixed all the race conditions reported.

The GC will cleanup the resources used by the goroutine once it
terminates, so what you're seeing is probably the transient response
of the system before it reaches a steady state.

>
> If I set the page refreshes to a larger number, such as 5 minutes, would the GC gobble up the unused goroutines fast enough that I wouldn't see much increase in memory use?

GC is fast enough, but the total number of concurrent requests you can
handle depends on how you handle your GET requests.

>
> Or am I thinking about this all wrong?
>
> TIA,
>
> Bucky
>

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/d2903306-e0b0-4e7e-a035-ff14b3c64c52%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[B Carr]

Thank you, that means I'm thinking correctly about this and need to keep plugging along.

>>"the total number of concurrent requests you can handle depends on how you handle your GET requests."

I'll need to study this a bit more. Can you give me a pointer?

[Burak Serdar]

I don't know really, other than the obvious ones like:

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/
https://golang.org/doc/ -> there's sections on concurrency patterns,
http servers, etc.

The most difficult and crucial thing with go is to change the way you
think about concurrency. For years I wrote programs in Java, and when
I started working with go, I looked for thread pools and thread local
variables. Learning to live without them was refreshing.

>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/052ac63e-259e-4e40-968f-0c5f66800b1b%40googlegroups.com.

[B Carr]

On Monday, July 8, 2019 at 1:01:26 PM UTC-6, Burak Serdar wrote:

> I'll need to study this a bit more. Can you give me a pointer?

I don't know really, other than the obvious ones like:

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/
https://golang.org/doc/  -> there's sections on concurrency patterns,
http servers, etc.

Thanks for that.

 

The most difficult and crucial thing with go is to change the way you
think about concurrency. For years I wrote programs in Java, and when
I started working with go, I looked for thread pools and thread local
variables. Learning to live without them was refreshing.

Since I'm coming to Go with zero background in concurrency there is nothing contaminating me. Fortunately...

[Michael Jones]

Very fortunate! 

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f658e6c9-7b73-4f25-a7db-4c5a95df79bd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael T. Jones
michae...@gmail.com