Closed CelticParser closed 8 years ago
@CelticParser Have you tried benchmarking nginx+http2 using the same node.js module?
It looks like this module is measuring TLS handshake time. This is even more evident considering that loadtest
does not seem to support nor http2, nor spdy (at least I don't see immediate dependencies, or any note in loadtest's readme), so you was just measuring a fallback server which is absolutely equal to default require('https').createServer(...)
.
I would suggest you to replace spdy
in your test code with https
, and make another run to see that it will give the same results without spdy
.
As an answer to your question, it doesn't seem to me that loadtest
is suitable for benchmarks here. I would suggest you to use h2load instead to benchmark HTTP2.
Thnx! Showing 7k req/sec. Now I know better.
I ran some performance tests using loadtest and had to take note by the drop in reqs/sec implementing
node-spdy
(-70%). It may be how I am using the module and would like some input.(Results below)
Using:
loadtest http://104.xxx.xxx.xx/ -t 40 -c 200 -k
Test serves a static index.html with a simple 40k jpg:
server.js uses buffet to grab the static content and put it into a buffer:
The configuration is pulled via
.confg.json5
:Load test using
required('html').createServer(function(req, res) {...
Using
spdy.createServer(confg.options, function(req, res) {...
as is above:I have also tested spdy omitting the
setHeader
function and that gives about a 1% boost with each test run. I have tried various ways of writing the server script (including hard-coding configs), but I consistently get the same results. I ran each test 5x each for an average. I also "de-hardened" the tests to find that errors start at around 10 req/sec.I would expect a slight drop in performance using spdy because of the TSL hand-shakes etc, but not a 70% drop. When I initially implemented the module I saw a decent performance increase (esp. w/push) in the developer console. A few days later I thought to load test it with a "real-world" scenario (20k index w/25 resources = ~600k downloaded_) and saw a 64req/sec rate! So I started looking into where the hit was. Again, I am not sure if my implementation is the cause(??). Serving static resources with Node & HTTP/1.1 is proving to be faster than using NGINX (and NGINX doesn't support "push" yet) and I would very much like to use
node-spdy
over NGINX in our product if we can get this figured out! Any input or insight will be greatly appreciated.