RArartichoke·Mar 4, 2013
I tested it with Go v1.0.3 vs Node v0.8.21 + Express v3.1.0
I used mgo with Go to connect to mongodb.
Then I filled it with 1,024 documents that was composed of 2 fields. One field with a few bytes of text and the other with a paragraph of text.
Then I created a few handlers to return:
1) 1x document as json
2) 7x documents as json
3) 15x documents as json
At 15x I decided this was likely going to generate a response large enough that there's no point going higher. It was about 25kb worth of json.
Then I used a lib called "routes":
https://github.com/drone/routes
It's not really close to what express does but it's better than nothing. Then I added in my own etag generator using the same method that express does (it gens it off the body length) for responses > 1kb.
Then I benchmarked each route 3 times with ab using:
-n 7500 -c {50, 250, 7
Read the rest
50, 1500}
I ignored the first and averaged the last 2 results.
I did this on a local VM locked down to 1 CPU with 512mb of ram with a c2d 2.13ghz CPU and a 7200 rpm sata HD.
Then I did the same with express using just bodyParser since neither setup had session support. Go didn't have a Redis store that was capable of working with the Gorilla session lib so I didn't use sessions on both setups.
I used the native mongodb driver for node.
Express was for the most part 10-15% faster where faster is more requests per second served. The latency was back and forth. I feel like the latency @ 99% was tighter with Go once the concurrency got really high but the amount was not enough to matter.
For example once I got to the higher concurrencies both were taking a ridiculous amount of time (over 7 seconds) on my old crappy desktop. Loading in 5.5 seconds instead of 7 seconds is not really "better" since it's abysmal on both.
Go is much better at responding with large amounts of data when the database call is eliminated. I can only assume its ability to deal with large strings is leaps and bounds superior to v8 which makes sense to me.
The thing is though, that's pretty much irrelevant. If I was going to serve static content I would be using S3 or nginx. If I'm serving dynamic content then I'm likely pulling this in from a database.