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

How we built Uber Engineering's highest query-per-second service using Go (2016)

eng.uber.com

Post reply on HN
Print view View original

81–90 of 124 posts

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#81

Post by kevan »

sokoloff wrote: post #13
Rapzid wrote: post #4

Earlier quoted context omitted.

With that kinda volume the 99th is not interesting at all. Should be looking at the 99.99th.

The latency to human user is what matters. If I get an answer in under 100ms as a user 99% of the time, I don’t care whether 100 or 100K times per day someone else hits that 1% worst case.

As an individual you don't care as long as you aren't in that 1%, but as a customer-obsessed service owner I absolutely care if a bad experience is happening 100k times per day. If you're operating at internet scale you need to look at both percentiles and absolute numbers to assess customer impact.

Also keep in mind how percentiles compound when you have more than one service involved in serving a customer request. For example, let's say it takes 5 internal requests to serve an external customer request and each of those services measures latency SLAs at the 99th percentile. The customer request may only finish inside the SLA 95% of the time (99%^5)

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#82

Post by jeltz »

Thaxll wrote: post #45
jeltz wrote: post #16

Earlier quoted context omitted.

Another rebuttal which is less through due to the benchmark being very synthetic but still points out that Uber's numbers are nothing impressive. https://www.cybertec-postgresql.com/en/beating-uber-with-a-p...

This is a crap article tbh They don't take any requierments and build a 5min poc with no constrains. For instance their demo doesn't update anything, Uber updates location every seconds, I'd like to see how PG behaves when you rebuild index thousand time per seconds.

No, that was not a requirement. This is not the database for the locations of cars, but the database with human defined geofences which probably only update a couple of times per day. The database is used to check e.g. if a customer is currently at an airport or not. That is a very normal and simple GIS workload.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#83

Post by triceratops »

Slartie wrote: post #14
merb wrote: post #10

Earlier quoted context omitted.

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.

From what I gathered off of several HN comments of Uber insiders, the size of their engineering team is actually more likely to be one of the causes for bad engineering decisions. They seem to have too many engineers running around for too little actual work to be done, which results in those engineers coming up with stuff to do to keep them busy (and of course to ensure they appear to be busy and worth their money t…

It might be sub-optimal for Uber but it's better for the industry as a whole to have many different implementations of the same type of solution.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#84

Post by elbear »

privateprofile wrote: post #66
0xEFF wrote: post #55

Earlier quoted context omitted.

> I guess Leetcoding and Production Engineering really are different things. This is key point. They delivered value to the business. That's the only thing that matters.

> They delivered value to the business. That's the only thing that matters. Except this is an engineering blog post, so the engineering part actually matters. And, as demonstrated in the article [1] linked around this discussion, there were better engineering approaches that would have been even "better for business", as being more efficient means lower costs per transaction and/or higher throughput. [1] https://medi…

It matters for engineers reading the article. It doesn't matter for the business. What they delivered was good enough. Could they have delivered a better solutions? Yes.

Should they have searched for a better solution instead of implementing the one they found? They could have spent some time researching, but you can always miss something. It's better to err on the side of delivering something now with a not-so-good solution than constantly searching for a better one.

I say this as software developer who is obsessed with efficiency. I'm starting to turn around and focus more on just delivering.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#85

Post by scottlamb »

sokoloff wrote: post #13
Rapzid wrote: post #4

Earlier quoted context omitted.

With that kinda volume the 99th is not interesting at all. Should be looking at the 99.99th.

The latency to human user is what matters. If I get an answer in under 100ms as a user 99% of the time, I don’t care whether 100 or 100K times per day someone else hits that 1% worst case.

> The latency to human user is what matters.

Agreed, which is why the most surprising part of this article for me was this phrase: "In our main data center serving non-China traffic".

The transit latency to the one main datacenter in the (non-China) world is a lot more significant than the server time here. (Over 50 ms just to cross the US; compare with their server-side latency numbers of 95%ile Or maybe the client is not the user's phone, but some other service running within the same datacenter?

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#86

Post by asdfman123 »

shantly wrote: post #47
sidlls wrote: post #31

Earlier quoted context omitted.

It's really true, in my experience. I managed a team in a company that used Spring Boot for services and batch jobs and Python for data and analytics (including ML). My team had its feet in both worlds so I had to hire for that. My experience trying to find programmers who could code and engineer first and not be slaves to the Spring framework was quite terrible in this context. Another thing of note: the python side…

I'm not sure what causes it—and I'm not even sure it's a bad thing, certainly it must not be hurting these folks careers too much, and maybe it's even helping them—but there's a certain path for developers that ends up leaving them helpless outside whatever narrow ecosystem they've grabbed onto. Usually it's Java or some Microsoft thing. As someone who very much did not develop (as a person/programmer) that way, it s…

Well, I think the difference between them and Silicon Valley programmers is that they don't constantly learn new technologies outside of work. It's just a 40-hour-a-week job.

I try to learn new things, but I don't do much programming outside of work. I could learn Node.js, for instance... but I've got other things I want to do.

Is that kind of what you mean?

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#87

Post by marcosdumay »

asdfman123 wrote: post #28
sidlls wrote: post #27

Earlier quoted context omitted.

They also would have to sift through some really terrible programmers who have fully bought into the worst practices of enterprise-y OO development.

Is that really true? Honest question. Or is that just bias against things that are not new and fancy?

Yes, hiring for mainstream languages have this cost. It's true whatever the quality of the language and how many good people are available to work on it.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#88

Post by forgottenpass »

thejigisup wrote: post #71
jzoch wrote: post #67

Earlier quoted context omitted.

While he was a bit rude I wouldnt assume he hasn't built something at this sort of scale.

nah i think its a pretty fair assumption

99% of people building at "scale" are borrowing bragging rights from a large company they happen to be employed by and/or tools they use while doing zero novel work unique to the size of their deployment.

To say that these paper tigers are above the bikeshedding of all the plebs is quintessential software echochamber.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#89

Post by geodel »

overcast wrote: post #62
matt2000 wrote: post #23

Earlier quoted context omitted.

My sense is that most people moving to Go are coming from Node and that explains their excitement about the performance. Not many upsides when you’re already on Java.

Why is it that every Java application I've encountered in my 20 years of corporate IT, has been a performance pig? Is it just a case of bad developers, making shit code? Is it difficult to make Java perform well, but when it does, it shines? I can't have accidentally interacted with ONLY the crappiest Java apps in my tenure.

I have exactly similar experience. At this point I feel Java programmer/developer is misnomer. Most of the time they are 'framework' fiddlers. Be it J2EE, Spring, Spring Boot (nowadays) Vert.x and so on. When I talk about an http server, the only frame of reference in their mind is Weblogic, Websphere, JBoss, Tomcat etc. The stuff they work with is 80% auto generated and they are quite proud if it.

So few application I own have about 200 LOC of business logic and 10K LOC Spring Boot fluff along with some 60 jar files which I am not sure what they really do.

Re: How we built Uber Engineering's highest query-per-second service using Go (2016)

#90

Post by CamouflagedKiwi »

MrBuddyCasino wrote: post #38
dashwav wrote: post #30

Earlier quoted context omitted.

I mean there is a definite performance gain from Java to Go, although I would agree most people probably wouldn't hit it - but if its just as easy to write, might as well use the better language. On top of that Go makes concurrency so much easier to factor in and program with, which in the backend server space is a very important asset over Java. As an interesting addendum, I found this to be a really interesting res…

> I mean there is a definite performance gain from Java to Go I don't think thats true.

There are dramatic memory and startup time improvements. Much less so for CPU once everything is up and running.
Post reply on HN