benchmarks about bud HOT 10 CLOSED

I would love to see how this compares with stud.

from bud.

I did some benchmarks and here is how it compares to stud right now, on small "hello world" response:

128 kb response:

from bud.

So it is significantly slower at bigger responses somehow, but has the same speed at small ones. I'll look into improving this situation, pretty sure that there are some space for optimization here.

from bud.

I believe in that too :) Good luck with the optimizations. I was worried of
stud because it has no activities recently. So bud would be a better
replacement.

On Mon, Dec 23, 2013 at 7:10 PM, Fedor Indutny [email protected]:

So it is significantly slower at bigger responses somehow, but has the
same speed at small ones. I'll look into improving this situation, pretty
sure that there are some space for optimization here.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-31119446
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

from bud.

Ha, nvm. I forgot to disable max_send_fragment option in bud. Here are correct results for 128kb body:

NOTE: I used 80 percentile, because 95 was too noisy...

from bud.

If anyone wants to reproduce those results, steps are following:

1. Spawn two smartos servers (one 16 core, other 4 core), clone https://github.com/indutny/bud-benchmark-comparison on both of them
2. cd bud-benchmark-comparison && ./init-server.sh
3. When 2 is done - cd bud-benchmark-compariso && ./init-client.sh <ip-of-your-server> && node process.js > results.csv && ./init-client.sh <ip-of-your-server> big && node process.js > results-big.csv
4. Load CSVs into google doc and create charts!

from bud.

Perhaps I'm misunderstanding max_send_fragment, but what exactly do you mean by "disable max_send_fragment"? Were you explicitly setting a lower max record size in first test? And if so, what was the record size set to? I presume "disabling" then would mean the default/max 16KB record size?

from bud.

Yep, I was setting it to 1400. When I disabled it - it was using default 16kb record size.

from bud.

I'm not denying that setting it to 1400 improves interactivity, just saying that makes maximum possible bandwidth significantly lower (and thus makes CPU usage higher).

from bud.

Right, ok - we're on the same page. Just wanted to make sure I'm interpreting the results correctly.

There is definitely a tradeoff here: smaller records lead to more framing overhead and more CPU cycles to compute the checksums, etc... Start small and boost the size to get the best of both worlds. :)

from bud.