5 ms·

Node will perform better under high concurrency too for most sized responses. Can you share evidence supporting this claim?

rartichoke 14y ago
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 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, 750, 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.
- tuxychandru 14y ago
  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. In my own micro-benchmark, I've seen that BSON decoding takes big chunk of time when using mgo. That should explain why the go version got faster when DB access was removed. This shouldn't come as a surprise as the node.js driver uses a BSON parser written in C++ by default.
  - rartichoke 14y ago
    It wasn't just a small difference though. The difference between returning 10kb of json from a function vs 10kb of json from mgo was insanely different. I don't think it's because the bson C++ implementation is so much faster than Go. I think it's because Go is clearly faster than JS but it doesn't matter once you introduce db calls. It's sort of like using "for in" vs "for" in JS in the browser. It doesn't really matter which one of them might be faster than the other, as soon as you touch the DOM the difference becomes meaningless and if you jsperf it with DOM touching the results will be the same.
- kevinfat 14y ago
  In my mind the big advantage of Go over Node that is sometimes overlooked is that your code in Go is written in a largely serial manner with no callbacks. With Go you don't have to deal with a lot of callbacks when doing I/O since goroutines are multiplexed on the underlying threads.
- BarkMore 14y ago
  Thank you for the detailed answer. Go 1.1 (to be released early next month) is across the board faster than 1.03. The ab tool is not ideal for testing the Go http server because the Go server is not tuned to ab's quirks. Siege might be better. The mgo client has the most bells and whistles, but it's probably not the fastest client for Go. One of the other clients might perform better. Why are the Go Redis clients not capable of working with Gorilla? A couple of the clients are well written and are fully functional.

rartichoke 14y ago

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 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, 750, 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.

tuxychandru 14y ago
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. In my own micro-benchmark, I've seen that BSON decoding takes big chunk of time when using mgo. That should explain why the go version got faster when DB access was removed. This shouldn't come as a surprise as the node.js driver uses a BSON parser written in C++ by default.
- rartichoke 14y ago
  It wasn't just a small difference though. The difference between returning 10kb of json from a function vs 10kb of json from mgo was insanely different. I don't think it's because the bson C++ implementation is so much faster than Go. I think it's because Go is clearly faster than JS but it doesn't matter once you introduce db calls. It's sort of like using "for in" vs "for" in JS in the browser. It doesn't really matter which one of them might be faster than the other, as soon as you touch the DOM the difference becomes meaningless and if you jsperf it with DOM touching the results will be the same.
kevinfat 14y ago
In my mind the big advantage of Go over Node that is sometimes overlooked is that your code in Go is written in a largely serial manner with no callbacks. With Go you don't have to deal with a lot of callbacks when doing I/O since goroutines are multiplexed on the underlying threads.
BarkMore 14y ago
Thank you for the detailed answer. Go 1.1 (to be released early next month) is across the board faster than 1.03. The ab tool is not ideal for testing the Go http server because the Go server is not tuned to ab's quirks. Siege might be better. The mgo client has the most bells and whistles, but it's probably not the fastest client for Go. One of the other clients might perform better. Why are the Go Redis clients not capable of working with Gorilla? A couple of the clients are well written and are fully functional.