Hacker News Reader

Comment by OhSoHumble | Hacker News Reader

"Too late for Go 1.8, but we can look into performance during Go 1.9."

That probably shouldn't be the response for a major performance regression in a release candidate.

Looks like I'm sticking to Go 1.7 for however long it'll take before 1.9 is released.

According to one comment it's a performance hit of about half a microsecond per request. It's certainly something that should be looked at and fixed if possible, but my guess is that 99.99% of applications out there are not affected at all by this issue.

So all your application does is accept connections, send hello world, and close them again?

Absolutely! I provide a "hello world as a service" platform.

How does it compare to https://github.com/salvatorecordiano/hello-world-as-a-servic..., which is written in JS / Node? Does yours do more requests / second? Do you have an enterprise plan?

I question that project's long-term viability. Event loop based languages inherently limit systems to inefficient and unreliable concurrency models.

My platform, which I've received seed funding for, is entirely done in Erlang. This technology decision will better enable me to deliver more hello worlds per nanosecond than Node ever could.

HWaaS

The theory is that also other programs will be affected, with a similar slowdown.

It's a regression in the closing of the connection in the http server in the standard library.

If really worried about performance, the fasthttp package is much faster than the one included in go.

"In short, fasthttp server is up to 10 times faster than net/http."

https://github.com/valyala/fasthttp

(And doesn't support HTTP/2, so pick your poison)

I thought the whole point of HTTP/2 was to transfer as many things as possible in one connection so maybe this bug is less of a concern for these types of connection.

The great thing is that now fasthttp can be a bit slower and still make that claim.

Sure, but what does "similar slowdown" mean?

The headline says "20%", which would imply that a "similar slowdown" for a 100 milliseconds response would bring it to 120 milliseconds.

But what is actually happening is that every request takes roughly an extra 0.04 milliseconds, so the time might go up to 100.04 milliseconds, probably within margin of error for most services anyway.

Seems like an easy debunk here is a test that has a more realistic response delay instead so that the slowdown can de demonstrated as an absolute amount vs. a percentage amount.

It's so hard to imagine high traffic application with api serving information to clients from array that is refreshed once in 10 minutes? So basically most of the time you touch only this array on every request which is like sending hello world example. In this situation it will be noticeable if you have a lot of traffic but then you would not use stdlib http library but something like fasthttp which doesn't change that there are other real world use cases that would be affected, not a lot of them but they exist.

That's why I posted this, too many people would be affected by such regression. And would prefer sticking to Go 1.7.x

> too many people would be affected by such regression.

Yes, too many people do stupid "hello world" tests indeed.

Maybe this is a problem with running "hello world" tests and not that much of a real-world problem. Let's see.

Nope, hardly anyone with real workloads will be affected.

Reply on news.ycombinator.com