Go is freakin' fast, I think
6 comments
There isn't really a big difference between a 'custom response' and any other kind - the reason you think so is because, generally, custom responses are handled by a slow scripting language with 'heavy' initial setup, while, non-custom is handled by the native web container code (apache, etc).
In this case, you're doing everything native, so custom response == normal response.
This isn't something specific to Go either, you'd get the same using C code, delphi, or almost the same using Java (Java being not quite the same in practice, as most Java devs will use a heavyweight container such as Tomcat).
In this case, you're doing everything native, so custom response == normal response.
This isn't something specific to Go either, you'd get the same using C code, delphi, or almost the same using Java (Java being not quite the same in practice, as most Java devs will use a heavyweight container such as Tomcat).
Good points. Likely C would be as fast, but a lot longer to code it. What I mean by custom is that every user gets a unique page. Unlike, say, Reddit, where concurrent users potentially see the same front page by default.
> Unlike, say, Reddit, where concurrent users potentially see the same front page by default.
Unless they're logged in. :)
Unless they're logged in. :)
These are excessively detailed numbers with very little context. What is the code doing? What's the performance of the equivalent implementation in another language (I'd be most interested in a typed language like Java)?
I realize you probably have more context in your head but for everyone else the body of the post adds very little to the title.
I realize you probably have more context in your head but for everyone else the body of the post adds very little to the title.
It might be just as fast in Java; I don't know. My only point is that theoretically being able to serve 78 million requests in a 10 hour day, most within 5 ms (server processing only) and each a unique gzipped page based on the user's past interaction with the site, all on a relatively cheap server, seems blazing fast to me. I'd think it was fast even if every user was shown the same page but each user's page was gzipped. Could Java match it?
"Could Java match it?" Dunno, you didn't upload the benchmarks :P
I'm sure a turtle seems fast in a snail POV.
I'm sure a turtle seems fast in a snail POV.
What is the source/what are you doing for each request? Are you going over the net for each request? 2k/sec really isn't that much to get excited about, I get 1k or so on Django on a $20 Linode. HTTPS?
If the code was simple I wouldn't be too impressed either. But a lot of processing goes into determining each of the 30 links to show the user. There's read locking and a sort on a ~1K-element slice in there too. The test was done on the server, nothing going across the net. In real use a page loads in as little as 150 ms, of which ~20 ms is the speed of light delay to/from the server.
It would be more interesting to see what's happening behind the scenes. Is the code open-source?
I've had good luck testing sites with LoadImpact. Give the free one a try.
Requests "fail" because the document length varies. I'm pretty blown away by Go's performance, especially knowing how much processing goes into producing a custom response to every request. Also every response is gzipped. (I'm using Go's web server and Sqlite.) The theoretical limit of requests that could be served in a 10 hour day from this single cheap server is 78 million. Now I just need some real users...