Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goroutines and APIs

blog.gnoack.org

Post reply on HN
Print view View original

1–10 of 31 posts

Re: Goroutines and APIs

#2

Post by asdfasgasdgasdg »

The blog seems sadly unable to tolerate the load. I don't see an archived version of the post anywhere either.

If I had to have a guess what it says, it's probably something along the lines of:

* Don't require users of your API to start goroutines to use your API correctly.

If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism.

* If possible, avoid high goroutine fanout in your implementation.

If a single request to your API fans out to 1k goroutines, it's going to be a problem for a high-traffic user of your API. Especially if there are other APIs that make the same design choice. As ever, try to be parsimonious with resource consumption.

IMO, these are two good principles to live by, and not just in Go.

Re: Goroutines and APIs

#3

Post by AndrewStephens »

I can't read the article but hopefully it does not ironically present advice on writing webservers.

There is really little excuse for a web server to buckle under pressure these days - hackernews sends a spike of traffic but not enough to kill even a moderately spec'ed server.

Re: Goroutines and APIs

#4

Post by jjbiotech »

asdfasgasdgasdg wrote: post #2

The blog seems sadly unable to tolerate the load. I don't see an archived version of the post anywhere either. If I had to have a guess what it says, it's probably something along the lines of: * Don't require users of your API to start goroutines to use your API correctly. If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism. * If possible,…

Doesn't the native net/http server spin up a goroutine for every request?

Edit: See line 2927 at https://golang.org/src/net/http/server.go

Re: Goroutines and APIs

#5

Post by asdfasgasdgasdg »

jjbiotech wrote: post #4
asdfasgasdgasdg wrote: post #2

The blog seems sadly unable to tolerate the load. I don't see an archived version of the post anywhere either. If I had to have a guess what it says, it's probably something along the lines of: * Don't require users of your API to start goroutines to use your API correctly. If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism. * If possible,…

Doesn't the native net/http server spin up a goroutine for every request? Edit: See line 2927 at https://golang.org/src/net/http/server.go

Yeah, but it doesn't spin up a thousand for every request. And it doesn't require you to start them. It starts them under the covers as part of the API.

Re: Goroutines and APIs

#6

Post by jjbiotech »

asdfasgasdgasdg wrote: post #5
jjbiotech wrote: post #4

Earlier quoted context omitted.

Doesn't the native net/http server spin up a goroutine for every request? Edit: See line 2927 at https://golang.org/src/net/http/server.go

Yeah, but it doesn't spin up a thousand for every request. And it doesn't require you to start them. It starts them under the covers as part of the API.

Right. So:

* Don't require users of your API to start [additional] goroutines to use your API correctly.

Re: Goroutines and APIs

#7

Post by jsd1982 »

AndrewStephens wrote: post #3

I can't read the article but hopefully it does not ironically present advice on writing webservers. There is really little excuse for a web server to buckle under pressure these days - hackernews sends a spike of traffic but not enough to kill even a moderately spec'ed server.

It'd only be ironic if the web server hosting the blog was a Go process, and even then it's a leap to conclude irony because the fault may lie outside the server process itself such as with the hosting company.

Re: Goroutines and APIs

#8

Post by asdfasgasdgasdg »

jjbiotech wrote: post #6
asdfasgasdgasdg wrote: post #5

Earlier quoted context omitted.

Yeah, but it doesn't spin up a thousand for every request. And it doesn't require you to start them. It starts them under the covers as part of the API.

Right. So: * Don't require users of your API to start [additional] goroutines to use your API correctly.

I guess what I mean to say is: don't make your users write

    go yourpackage.YourApiCall()
in order to use the API correctly. That's just a guess, though.

Re: Goroutines and APIs

#10

Post by gnoack »

asdfasgasdgasdg wrote: post #2

The blog seems sadly unable to tolerate the load. I don't see an archived version of the post anywhere either. If I had to have a guess what it says, it's probably something along the lines of: * Don't require users of your API to start goroutines to use your API correctly. If Goroutines need to be started for your API to work, start them in an init function, on first use, or via some other mechanism. * If possible,…

(whoops, excuse the bad webserver config... should be fixed now)

> Don't require users of your API to start goroutines to use your API correctly.

Actually, what I postulate in the article is different... The theory is that making the caller kick off the goroutines puts more control over concurrency into the hands of the caller, and the resulting API is simpler.

> Avoid high goroutine fanout in your implementation.

That's for sure. :)

Post reply on HN