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

101–109 of 109 posts

Re: Handling 1M Requests per Minute with Go

#101

Post by meir_yanovich »

nindalf wrote: post #82
meir_yanovich wrote: post #78

Can you please explain why to use go and not c++/c forget about language syntax / compilation complexity. say i know both very well , now why to go with "GO" ? thanks

There are a few benefits of Go I can think of * Fewer lines of code, fewer gotchas and hence easier to reason about and maintain. * Powerful concurrency primitives (channels, select) built right into the language, rather than a library. A scalable producer-consumer implementation would probably be 100 lines of Go code. * If your application isn't too latency sensitive (game server, frequency trading etc) then the GC…

Thank you for the reasoned reply.

Re: Handling 1M Requests per Minute with Go

#102

Post by anonyfox »

istvan__ wrote: post #99

Is this supposed to be great performance? I think Netty does ~30K/s (1800000 req/min) out of the box. It thought Go has more out of the box performance, maybe I am missing something.

Oh, performance? Let's throw numbers around! Here, Elixir/Phoenix beats them all!

https://twitter.com/julianobs/status/614416512825323520

Hey, and Elixir is already way more expressive than Go and it's incredibly easy to build fault-tolerant and distributed systems, not to mention the productivity gains when using the phoenix framework!

Seriously, posting requests/second metric without any context about hardware and sample code doesn't help anyone.

Re: Handling 1M Requests per Minute with Go

#103

Post by arthurcolle »

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

I was always a big fan of Erlang's concurrency model but I've really been getting into Elixir lately. It is just such a productive language to write and lends itself to extremely maintainable codebases.

Re: Handling 1M Requests per Minute with Go

#104

Post by istvan__ »

anonyfox wrote: post #102
istvan__ wrote: post #99

Is this supposed to be great performance? I think Netty does ~30K/s (1800000 req/min) out of the box. It thought Go has more out of the box performance, maybe I am missing something.

Oh, performance? Let's throw numbers around! Here, Elixir/Phoenix beats them all! https://twitter.com/julianobs/status/614416512825323520 Hey, and Elixir is already way more expressive than Go and it's incredibly easy to build fault-tolerant and distributed systems, not to mention the productivity gains when using the phoenix framework! Seriously, posting requests/second metric without any context about hardware and…

Cool it is only 10-16x slower than Aleph. https://github.com/ptaoussanis/clojure-web-server-benchmarks...

Re: Handling 1M Requests per Minute with Go

#105

Post by anonyfox »

istvan__ wrote: post #104
anonyfox wrote: post #102

Earlier quoted context omitted.

Oh, performance? Let's throw numbers around! Here, Elixir/Phoenix beats them all! https://twitter.com/julianobs/status/614416512825323520 Hey, and Elixir is already way more expressive than Go and it's incredibly easy to build fault-tolerant and distributed systems, not to mention the productivity gains when using the phoenix framework! Seriously, posting requests/second metric without any context about hardware and…

Cool it is only 10-16x slower than Aleph. https://github.com/ptaoussanis/clojure-web-server-benchmarks...

full blown mvc framework vs communication layer, seems legit :)

but hey, as long as stuff responds in microseconds with zero errors under load, just use it ! (Also, clojure is a way better language than go, too.)

Re: Handling 1M Requests per Minute with Go

#106

Post by peterwaller »

ignoramous wrote: post #95
peterwaller wrote: post #45

There are two other solutions that spring to mind, which might require quite a bit less code: 1) Take the original code, do the upload exactly in place in the original request (not even spawning a goroutine). However: protect the upload with a semaphore which only allows N-in-flight. My reasoning is, well, if the system operates with low latency when operating nominally, blocking the incoming request isn't too painfu…

Re: Semaphore: Not dropping the connection might mean we might starve others incoming msgs of resources (which might be a good thing) [0]. Also, releasing the semaphore back into the pool in case of failures takes on a happy complication of having to deal with errors beyond one's control. Re: Queue: Wouldn't the queue involve locking lest two workers end up trying to work on the same request? To be completely concurr…

Semaphore, I'm suggesting:

  Block on N-Semaphore, with timeout
  Do timeout upload
  Replace N-Semaphore
If you don't always replace the semaphore, that's a bug.

Queue: I'm just comparing to what the article does. It already has contention on a queue (the chan), it's just the chan-chan-Worker rather than chan-Job. In practice, go channels happily handle millions of messages contending to multiple workers just fine. Consider this test example where you aren't even actually burning any CPU to perform the work:

    package main
    
    func main() {
        q := make(chan int)    
        for i := 0; i
On my laptop, it runs in 0.333s single core, and it's slightly slower when you set GOMAXPROCS > 1. But not much slower, the total runtime goes to 0.4-0.5s or so. (Measured with go 1.4). As soon as you do any actual work with the messages you are passing around, the overhead of locking will be lost in the noise.

Re: Handling 1M Requests per Minute with Go

#107

Post by anewhnaccount »

mrfusion wrote: post #23

It's interesting this came up today. I'm looking for a new language to migrate my flask/uwsgi web service to. I'm having a terrible time making it scale. Are there any tutorials/templates/best practices for writing a small web service in Golang?

Before you rewrite in another language? Have you benchmarked it? Are you sure you know where the bottleneck is?

Re: Handling 1M Requests per Minute with Go

#108

Post by nindalf »

meir_yanovich wrote: post #101
nindalf wrote: post #82

Earlier quoted context omitted.

There are a few benefits of Go I can think of * Fewer lines of code, fewer gotchas and hence easier to reason about and maintain. * Powerful concurrency primitives (channels, select) built right into the language, rather than a library. A scalable producer-consumer implementation would probably be 100 lines of Go code. * If your application isn't too latency sensitive (game server, frequency trading etc) then the GC…

Thank you for the reasoned reply.

You're welcome :)

Re: Handling 1M Requests per Minute with Go

#109

Post by istvan__ »

anonyfox wrote: post #105
istvan__ wrote: post #104

Earlier quoted context omitted.

Cool it is only 10-16x slower than Aleph. https://github.com/ptaoussanis/clojure-web-server-benchmarks...

full blown mvc framework vs communication layer, seems legit :) but hey, as long as stuff responds in microseconds with zero errors under load, just use it ! (Also, clojure is a way better language than go, too.)

Yes I like to throw meaningless numbers around as much as the other guy. :)
Post reply on HN