How we built Uber Engineering's highest query-per-second service using Go (2016)
1–10 of 124 posts
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#2> High performance in throughput and latency. In our main data center serving non-China traffic alone, this service handled a peak load of 170k QPS with 40 machines running at 35% CPU usage on NYE 2015. The response time was > Geofence lookups are required on every request from Uber’s mobile apps and must quickly (99th percentile For a 100ms total budget, a ~50ms 99th percentile for a single microservice doesn't sound like something to boast about.
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#3> High performance in throughput and latency. In our main data center serving non-China traffic alone, this service handled a peak load of 170k QPS with 40 machines running at 35% CPU usage on NYE 2015. The response time was > Geofence lookups are required on every request from Uber’s mobile apps and must quickly (99th percentile For a 100ms total budget, a ~50ms 99th percentile for a single microservice doesn't soun…
I don’t read this the way you do. I read it as their service had to answer under 100ms and they made it run under 50
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#4> High performance in throughput and latency. In our main data center serving non-China traffic alone, this service handled a peak load of 170k QPS with 40 machines running at 35% CPU usage on NYE 2015. The response time was > Geofence lookups are required on every request from Uber’s mobile apps and must quickly (99th percentile For a 100ms total budget, a ~50ms 99th percentile for a single microservice doesn't soun…
With that kinda volume the 99th is not interesting at all. Should be looking at the 99.99th.
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#5it's sad to see these "moved from X language to Y language and it became faster!" every-time.
If the CPU is the hugest bottleneck, the best answer is not to optimize the algorithm by going to a lower level language, but rather to invest in a different architecture like GPGPU or FPGA.
For example, this paper shows a significant speed-up for PIP( Polygon in Point) algorithm, going from 15hs (CPU) to a mere 11sec (GPU) in task load-time. https://pdfs.semanticscholar.org/1e51/e3c681e1afc908a41ac253...
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#6it's sad to see these "moved from X language to Y language and it became faster!" every-time. If the CPU is the hugest bottleneck, the best answer is not to optimize the algorithm by going to a lower level language, but rather to invest in a different architecture like GPGPU or FPGA. For example, this paper shows a significant speed-up for PIP( Polygon in Point) algorithm, going from 15hs (CPU) to a mere 11sec (GPU)…
That is high throughput design, not a low latency design, which is what they are optimising for here. It is a very different design space.
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#7Related from 2018: https://news.ycombinator.com/item?id=16093192 and https://news.ycombinator.com/item?id=16084090.
Discussed at the time: https://news.ycombinator.com/item?id=11205776.
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#8There's a famous 'rebuttal' post to this here https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#9There's a famous 'rebuttal' post to this here https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...
Thank you for this :))
Re: How we built Uber Engineering's highest query-per-second service using Go (2016)
#10There's a famous 'rebuttal' post to this here https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...
well basically ubers blog posts are really low quality and from the outside their engineering descisions are kinda vague.
like the switch from postgres to mysql.
I'm still clueless how you can have so much money and one of the biggest engineering team, but still can't correctly engineer your stuff. I mean, everybody makes wrong decisions or errors in production code.