On Saturday, December 12, 2015 at 5:23:13 AM UTC+7, Dave Cheney wrote:
You can investigate this yourself, write a small hello world style Go
program, run it with the env var GODEBUG=gctrace=1000 and hit it with some
kind of load testing software. The runtime will output a summary of the run
queue once per second. Dmitry has a good blog post describing this output
in more detail,https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs
Okay, so I am a few days into learning go and I am trying to understand the
go routines. The two things I heard so far about them( in a redundant
manner) is, that they are very cheap and that it is easy to reason about
architectures that are build with them. I would like to build an opinion on
different ways of composing these go routines, because I don't want to
implement and measure all possibilities for every design decision. Even
though I believe, go comes with good tools for this. :-)
I didn't mean that the scheduling overhead increases based
on the number of goroutines. I meant that the scheduling overhead
increases based on the amount of work there is to do.
Okay, but there is other overhead, than scheduling overhead attached to a
goroutine, right? like the blocked OS-Thread, when the goroutine does a
syscall. And there is a maximum number of threads (set by default to
10000). So if there is a peak in requests, either by an increased amount of
users, or because an adversary floods the server with requests, the server
could crash pretty quickly. I just somehow have the suspicion, that it is
not a good idea to create go routines in direct relation to the input of a
program. Especially, when the input comes from the network, because it
could lead to potential Denial Of Service vulnerabilities. This cant really
be mitigated by a higher number of maxthreads, because eventually the
operating system will crash. I would be glad to hear if this train of
thought is right.
During my digging I found this paper:http://www1.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf
I couldn't find a discussion about it and if the considerations were
accepted and implemented. If that is the case, the kind of architecture I
thought of would be better, because the grouping of goroutines, proposed in
this paper, works on the assumption that the goroutines communicate with
each other over channels. The current net/http package has a lot of
goroutines, that don't interact with each other, so this grouping yields no
performance benefit. It would be nice, if someone could point me to the
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 email@example.com.
For more options, visit https://groups.google.com/d/optout.