On Concurrency in Go HTTP Servers | Hacker News Reader

On Concurrency in Go HTTP Servers

eli.thegreenplace.net

81 pointssigna1126 comments

Ugh. This is only going to mislead newbies and irritate the experienced people who will end up reviewing their code.

Channel sends and receives have non-trivial costs associated with them.

When you choose to model your problem with channel communication, you better be sure you’re doing enough work before and/or after the send/recv to justify involving the scheduler.

I’ve reviewed code where new engineers spawn unbounded goroutines... for each goroutine to then go on to compute the distance between two points on a two dimensional plane... aggregate the results on a channel and compute a sum.

Say channels were always low overhead, two orders of magnitude faster in general or optimized out completely in cases where even that overhead was too much. Would it still make a difference?

I believe performance is only a small part of the problem, channels in Go are just too awkward to use.

I haven't done a ton of go programming but the last small web app I wrote we sent closures over a channel to serialize access to a sqlite database. Channels felt like a nice clean way to handle that.

Yes, sending closures over channels is a very convenient and flexible concurrency framework. In fact it would be handy for all channels to have a standard handler attached, that pulls closures from the channel and executes them. Among other benefits that would mean you didn’t need a separate “go” keyword; to execute a function in the background you just post it to a channel. That’s basically how Java thread pools and Grand Central Dispatch work.

The idiom of defining message types that you post to a channel so that you can pull them from the channel and execute them strikes me as boilerplate. What you really want to do is run some code in a particular thread context; so why not just do that directly?

Are there useful things you do with channels that can’t easily be done with thread pools?

That’s really cool.

They’re too awkward to throw at every problem, but they are definitely useful for things like serialization. The ergonomics could be improved, however.

The author does call this out:

> While it certainly looks like an interesting technique, for our particular use case this approach seems like an overkill. In fact, overuse of channels is one of the common gotchas for Go beginners. Quoting from the Go Wiki entry:

> > Most locking issues can be solved using either channels or traditional locks.

> So which should you use?

> Use whichever is most expressive and/or most simple. It then goes on to suggest that mutexes are preferable for protecting shared state. I tend to agree, since a mutex feels more natural here.

Like how compilers can choose to not actually not emit a method call when you have a method call in your source code and instead just inline the code from the method, could the Go compiler chose to not actually write to a channel and just instead run the action of the goroutine where it receive from the channel at that point? The scheduler semantics would allow that wouldn't they?

CSP is one of Go's killer features and it is going to get overused by newbies regardless of this article. But that is part of the process that everyone goes through learning a new language and hopefully the experienced people will try to be good mentors and help them gain a more balance view of their use and not get irritated.

I find it to always be either overused or underused.

Either the app is a vanilla evented io web application, in which case you could write it in pretty much any major language using an evented framework. Or it's a mess of buggy channel usage.

I guess there's a happy balance of "let the library maintainers do the hard channel work" but to be honest I can use someone else's high performance evented io library in any language.

My experiences doesn't reflect yours exactly, but I know what you mean. Go is still a fairly young language, so I think the patterns are still establishing themselves. But I think progress is being made and much of the code I've seen lately has been pretty good.

Regarding libraries, best practice is to use CSP sparingly and to design the API as blocking calls so the applications have the choice of using the call directly or wrapping it with CSP.

Would it be fair to say it should be rare to see channels passed directly in the parameters or return types of a public API?

If so, it feels to me like channels are a bit of a misfeature. They work OK as a way to implement concurrency, sure, but not in a way that you want to expose in your API. They’re not very composable.

(That’s a bit hand-wavy as I’m not a heavy Go user. If there are good uses of channels in public APIs I’d be interested to hear about them.)

Compare to e.g. maps, or closures. Those are very generally useful and composable primitives and it’s therefore common to see them used directly in APIs.

> Would it be fair to say it should be rare to see channels passed directly in the parameters or return types of a public API?

Yes, it is pretty rare. The only example I know off the top of my head is the ssh library, but I would say it is an appropriate and good use of them and you can look at that as a possible example.

https://godoc.org/golang.org/x/crypto/ssh

> If so, it feels to me like channels are a bit of a misfeature. They work OK as a way to implement concurrency, sure, but not in a way that you want to expose in your API. They’re not very composable.

If you just look at channels and goroutines without some knowledge of CSP they will look a bit rough and low level, but once you understand CSP you'll see they are one of the better primitives available today. IMO the main problem with them is that people try to just use them without really understanding how to use them and it is pretty easy to shoot yourself in the foot with them.

Yes, officially, channels should be rarely seen in library APIs. This is because most of the time the library is doing something that should be simply done synchronously. If a consumer of your library wants to do something with that synchronous operation, it is up to them to use the concurrency tools to do so. You can't provide a library that is as flexible as what the language already offers, because you can't help but hard-code some aspect of what is going to be done.

But there are rare cases where you may want to offer them. I find a pattern I often have is to officially provide a method or set of methods that do whatever the thing is, but if you have a sophisticated case where you may need the thing the library is doing to participate in a select, you can offer a channel. There's often additional responsibilities for the caller that come with it when I do that. But it's more efficient that asking them to spawn a brand new goroutine just to call my code that is just going to drain a channel for them. Some particularly advanced fixtures may even have their own internal plumbing bits, but you normally shouldn't care about those.

Channels are fairly composible, it's just that it shouldn't be libraries doing the composing. To use a rough physical equivalent, your sink, dishwasher, toilet, and shower don't come with their own pipes to hook into the system, because whoever made those things have no idea what your local concerns will be. Fixtures are the library functionality, and the channels are the local plumbing. It's not a perfect metaphor, since physical objects intrinsically fix more aspects than code does, so don't pick at it too hard, it's just something to get an idea across.

(They'll get more composable with the new generics stuff, when it comes out. Although possibly dangerously so; generic channel libraries are going to make it easy to compose yourself up some local plumbing that involves way too many hidden goroutines and channels and will make it easy to trash performance.)

For the record, I'm not irritated by the newbies. I'm irritated by guidance like the OP.

I read these sorts of articles as a learning exercise by the author. Teaching others is often considered one of the better ways to learn a subject and just look at them that way. And I assume new users will make those same mistakes anyways, so it doesn't bother me.

I think this is a rather confusing article for beginners. I would say that request processing in an HTTP framework isn’t exactly a practical use case to demonstrate Go concurrency features. Most real-world applications are based on REST, which is stateless. In fact I would not associate HTTP server frameworks (in Go or in whatever language) with internal shared state management in an entry level article. For people interested in Go concurrency features there’s this great curated list instead:

https://github.com/golang/go/wiki/LearnConcurrency

I am unfamiliar with how Go HTTP frameworks do things but in Elixir each request is a new process... and running in BEAM which was designed for massive concurrency from the beginning. Go is frequently compared to BEAM solutions so I'm curious if each request in a Go web framework spawns a separate process per request.

Go shouldn't be compared to BEAM at all. It doesn't have processes. It spawns a lightweight thread (goroutine) on each request.

BEAM's "processes" are lightweight too AIUI, pretty similar to goroutines.

Go’s web framework does spawn a goroutine for each request.

Seems odd not to mention sync.Map at least in passing.

It's got a lot of gotchas and is not intended to be a simple replacement for map+mutex (certainly not in this case).

Actually, this is exactly a scenario in which a sync.Map would be useful. Typically, you would use pointers to atomic integers as the sync.Map values in a case like this.

In most situations shouldn’t you be storing state-like items like counters in your db which is atomic in any case?!

This isn't the kind of thing anyone can answer without a real world scenario. An abstract problem like a counter may or may not need to be in the DB, and just because you have a DB doesn't mean you should rely on it for locking or atomicity (maybe you have a read replica and your writes/reads are happening in different places, maybe the data is only useful temporarily and if the service dies it doesn't matter that it's lost, etc.)

Reply on news.ycombinator.com