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

Handling 1M Requests per Minute with Go

marcio.io

Post reply on HN
Print view View original

51–60 of 109 posts

Re: Handling 1M Requests per Minute with Go

#51

Post by fasteo »

Ao7bei3s wrote: post #13
fasteo wrote: post #6

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system I don't get this reasoning.

Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...

>>> It makes perfect sense to me

Yes. Other than some very basic scripts, I have never worked with Ruby, so I was not aware that it is so slow. Thanks for pointing that out.

As for my recommendation, it is pretty standard worker architecture:

Their system seems to be an ingesting-only system, that is, the clients are getting an empty HTTP 200 OK response. Given this, I would put openresty (nginx) in the front, with some trivial Lua code[1] to en-queue payloads to beanstalkd. Then, you can either have your workers inside openresty (using Openresty timers) or have them as separate processes and written in the language of choice. We have been using this for a couple of years now and it is working really well for our use case, also an ingesting-only system.

[1] https://github.com/smallfish/lua-resty-beanstalkd/blob/maste...

Re: Handling 1M Requests per Minute with Go

#52

Post by plydatbk »

thequailman wrote: post #44
plydatbk wrote: post #34

Earlier quoted context omitted.

the only reason to write something like that in Go is if you're looking to impress a recruiter at (Go). Advise: pick a better tool for your problem.

This is terrible advice. Golang may have a flavor-of-the-week status in some people's minds, but it's a language that really deserves more credit. It is really easy to program and learn, and it does a lot of stuff other languages rely on third party programs for. With each release, nagging issues (namely around garbage collection) are getting resolved, but it's more than production ready. To ignore Golang right now w…

Sitting at a corporation and learning Java may have been a popular thing to do to join the "boys" club in the early 2000s but I promise you that won't last forever. It's not bad advise to pick a target and actually point at it instead of wasting time solving a problem that has already been fixed.

Re: Handling 1M Requests per Minute with Go

#53

Post by saosebastiao »

Ao7bei3s wrote: post #13
fasteo wrote: post #6

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system I don't get this reasoning.

Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...

Scala, Java, Clojure, C#, F#, Node, LuaJIT, Erlang, Elixir, Haskell, D, Nim... There are lots of reasonably fast options out there that aren't C.

Re: Handling 1M Requests per Minute with Go

#54

Post by Udo »

I was confused by the numbers at first, so: that's 17k requests per second, spread out over 4 dual core Xeon (Haswell) machines, which works out to just over 4000 requests/s per machine. It's still a respectable number, but it's much closer to what one would expect given the task.

Don't get me wrong, the most interesting part is definitely the implementation and as a Go noob I found it very useful - it's just a bit misleading for the headline to sum your request rate across all parallelized machines.

Re: Handling 1M Requests per Minute with Go

#55

Post by muraiki »

sbov wrote: post #49
thequailman wrote: post #44

Earlier quoted context omitted.

This is terrible advice. Golang may have a flavor-of-the-week status in some people's minds, but it's a language that really deserves more credit. It is really easy to program and learn, and it does a lot of stuff other languages rely on third party programs for. With each release, nagging issues (namely around garbage collection) are getting resolved, but it's more than production ready. To ignore Golang right now w…

Golang has my attention, but I don't think it's anywhere near Java, at least popularity-wise, in the early 2000s. By then most schools had already switched their language of choice to Java - I'm not aware of any that has switched theirs to Golang. I do enjoy coding in Golang, but we use mostly Java where I work, and for us, the benefits don't make up for the things we lose. This blog post is a great example: the solu…

Yeah, I remember wanting to do a fan-out pattern in Go and reading the Go Pipelines and Cancellation article[0]. I saw the function merge() in the article and thought, "Great, here's what I need!" I then proceeded to read further and saw that I have to define this function myself based on the types I'm using, which made me quite sad.

Go really needs a library for these patterns built in... I assume the lack of generics prevents users from creating that themselves (I'm not trying to start a language war here, seriously).

[0] http://blog.golang.org/pipelines

Re: Handling 1M Requests per Minute with Go

#56

Post by pjmlp »

Ao7bei3s wrote: post #13
fasteo wrote: post #6

>> But since the beginning, our team knew that we should do this in Go because during the discussion phases we saw this could be potentially a very large traffic system I don't get this reasoning.

Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...

> Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in.

Than MRI Ruby you mean.

The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.

Re: Handling 1M Requests per Minute with Go

#57

Post by dragonwriter »

pjmlp wrote: post #56
Ao7bei3s wrote: post #13

Earlier quoted context omitted.

Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. It makes perfect sense to me. What would you have recommended them, for a reasonably-high-performance server implementation? (Please don't say C.) https://benchmarksgame.alioth.debian.org/u64q/benchmark.php?...

> Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in. Than MRI Ruby you mean. The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.

> > Go is 1-2 orders of magnitude faster than Ruby, and much easier to write concurrent code in.

> Than MRI Ruby you mean.

Given the nature of orders-of-magnitude comparisons and the lack of Ruby implementations that are even one order of magnitude faster than MRI, "...than Ruby" is reasonably accurate if "...than MRI Ruby" is at all accurate.

> The advantage wouldn't be as much if Ruby designers cared to add AOT compilation in the same vein as Dylan or Common Lisp to the canonical implementation.

Maybe, though that's unproven. AFAIK, actual Ruby implementations with AOT only seem to gain about a factor of 2 improvement, not an order of magnitude.

Re: Handling 1M Requests per Minute with Go

#58

Post by blakesmith »

wpeterson wrote: post #11

If this system is merely decoding JSON and writing payloads to S3 for asynchronous data processing, why not have your clients write directly to S3?

I'm not the author of the article, but if I'd have to guess: Data encapsulation, and interface control. If all your clients are talking directly to S3 instead of your encapsulated service interface, you can't inject any business logic at all and must design around the fact that you don't control the service interface, Amazon does.

Re: Handling 1M Requests per Minute with Go

#59

Post by mrfusion »

f2f wrote: post #31
mrfusion wrote: post #25

Mods, can we change "go" in the title to "golang"? That's the official name, and it makes it searchable by search engines?

I'm sorry but the official name is Go. You can search for "Golang" or "Go Language" with no issue.

Would this thread come up under one of your suggested searches?

Re: Handling 1M Requests per Minute with Go

#60

Post by f2f »

mrfusion wrote: post #59
f2f wrote: post #31

Earlier quoted context omitted.

I'm sorry but the official name is Go. You can search for "Golang" or "Go Language" with no issue.

Would this thread come up under one of your suggested searches?

both the original article and the Reddit discussion come up in my results (as 1 and 2). the reddit discussion is only 16 hours old.

https://www.google.com/search?q=golang%201%20million&rct=j

this HN discussion is too recent to show up in my results, however yesterday's thread about Qihoo and golang does show up as number 4 or 5 when searching for "golang qihoo".

no need to panic.

Post reply on HN