[deleted]
Handling 1M Requests per Minute with Go
71–80 of 109 posts
Re: Handling 1M Requests per Minute with Go
#72>> 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?...
There's nothing concurrent in this case, parallel sure, but concurrency wise this is all shared nothing. And languages are not faster than one another. They are faster at certain tasks but the variability for a given task is really case specific. For io heavy workloads like this underlying libraries and implementations dominate execution time.
You could have written this in any number of languages. I don't know why go is more logical than say Java JavaScript.
Re: Handling 1M Requests per Minute with Go
#73Does anybody here have any experience with Go's garbage collection pauses with large stack sizes? I've got a scala app that regularly consumes about 48G of ram, and I'm very happy with the response times during heavy loads like this, but the P99.5 is abysmal because of garbage collection. I've tried tuning it, but it doesn't seem like anything I do helps. I'll probably end up using an Azul JVM but I'm curious how oth…
> I've got a scala app that regularly consumes about 48G of ram, and I'm very happy with the response times during heavy loads like this, but the P99.5 is abysmal because of garbage collection. I've tried tuning it, but it doesn't seem like anything I do helps. When tuning a prod Scala deployment a while back, I encountered a nasty "pregnant pause" every once in a while similar to what you have experienced. So, below…
Have you tried the new G1 GC? I'm not very familiar with GC tuning, but I thought using the CMS GC with vary large heaps is asking for trouble. Apparently the G1 GC alleviates this, and still manages to be as "cool" as the CMS GC.
Re: Handling 1M Requests per Minute with Go
#74Little confused here.So the third solution mentioned in the post is just a worker pool? I think if we just slightly modified the second solution, it will totally work.
1).Initialize a job channel
2).Initialize a set of workers that listen to this channel to pull the jobs indefinitely. In this case just call go StartProcessor() for fixed number of times.
What confuses me is that IMO workPoolChannel isn't necessary here. What is the consideration behind to use a channel for workers?
Re: Handling 1M Requests per Minute with Go
#75>> 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.
It's less about Go being incredibly fast than about Ruby being anomalously slow. It makes sense if you start from the presumption that Go is the only "fast" language they're considering.
Frankly, if you're going to be processing requests and shuffling them to S3, Ruby is nowhere near being the limiting factor unless you do something pathologically bad.
Having spent time recently optimizing a setup that does pretty much exactly what they're doing (in Rails; I don't like Rails, but in this case Rails is not a problem), the time saved doing things like eliminating unnecessary buffering all over the place (e.g. POSTs gets buffered by pretty much everything that likes to consider itself a web server, sometimes multiple times; if you e.g. run Nginx in front of pretty much any Ruby web servers running Rails, worst case you may end up with things passed through at least 3, possibly 4 buffers).
Basically they should be IO bound.
Re: Handling 1M Requests per Minute with Go
#76[deleted]
Re: Handling 1M Requests per Minute with Go
#77Earlier quoted context omitted.
> I've got a scala app that regularly consumes about 48G of ram, and I'm very happy with the response times during heavy loads like this, but the P99.5 is abysmal because of garbage collection. I've tried tuning it, but it doesn't seem like anything I do helps. When tuning a prod Scala deployment a while back, I encountered a nasty "pregnant pause" every once in a while similar to what you have experienced. So, below…
Have you tried the new G1 GC? I'm not very familiar with GC tuning, but I thought using the CMS GC with vary large heaps is asking for trouble. Apparently the G1 GC alleviates this, and still manages to be as "cool" as the CMS GC.
> Have you tried the new G1 GC?
IIRC, I did and it didn't benchmark well for my needs. However, it all depends on what JRE you're using and what the system is doing to pick the GC which is best for any given deployment. Classic case of YMMV and all that.
In the end, even though it may sound trite, the only way to know what works best for a given combination of JRE/OS/hardware is to measure it. This article[1] had some good tips and Mission Control[2] is a huge help in this arena.
1 - http://www.infoq.com/articles/Tuning-Java-Servers?utm_source...
2 - http://docs.oracle.com/javacomponents/jmc-5-5/jmc-user-guide...
Re: Handling 1M Requests per Minute with Go
#78Can 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
Re: Handling 1M Requests per Minute with Go
#79There 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…
Timeout/Retry/ExponentialBackOff
Re: Handling 1M Requests per Minute with Go
#80Earlier quoted context omitted.
As Clojure would beat Lua every second of a day.
I'm a big clojure fan and not the biggest Lua fan, but I'm afraid you are mistaken. You won't find any dynamically typed language implementation that can come close to LuaJIT for the general use case.
What if you type hint everything in Clojure properly so all reflection is avoided? (does take some time, but with something like YourKit it'll be only a few hours max on a mid-size project)