Perhaps a dumb question: Are the headers the same? With so small files, the header layout is suddenly very important for your measurement.
I've seen my share of web servers which are very different in their compliance.
Vert.x (JVM async) vs Node.js Http benchmarks results
11–20 of 122 posts
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#12Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another. There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.
I agree the "micro" benchmark isn't something people should look to as a definitive answer, but I don't think they should be outright dismissed either. If nothing else, they should be a jumping off point for real testing.
I agree that micro benchmarks are kind of useful in spotting anomalous, bad performance in the very simplest of cases.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#13Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another. There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.
Related-
http://blog.yafla.com/Pet_Store_2011__Metrics_Instead_of_Eva...
These micro-benchmarks aren't even a good kicking off point for comparisons, as the things that yield a trivial benchmark win are often the things that yield significant performance troubles at scale.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#14Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another. There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.
Hardly meaningless. The problem is that the larger application benchmarks fall prey to accusations of "I wouldn't write it that way!". Their results are just as hotly disputed.
This micro-benchmark makes sense. It's benchmarking an HTTP server essentially. Any benchmark further than this would really be benchmarking the JVM and V8. While that would be interesting, I think in this case, this micro benchmark is OK as long as you know its limitations.
The reality is that most people's app code and databases are going to bottleneck long before either Vert.x or Node.js do. The main thing this benchmark clears up is that both of them are really, really, fast, and that if you do lots of simple to process responses you may want to go with Vert.x.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#15Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another. There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.
Hardly meaningless. The problem is that the larger application benchmarks fall prey to accusations of "I wouldn't write it that way!". Their results are just as hotly disputed. This micro-benchmark makes sense. It's benchmarking an HTTP server essentially. Any benchmark further than this would really be benchmarking the JVM and V8. While that would be interesting, I think in this case, this micro benchmark is OK as l…
> This micro-benchmark makes sense. It's benchmarking an HTTP server essentially.
Kind-of true. But to give any results that can be applied to the real world, it would have to use a much larger payload than a hello world.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#16Don't serve static files with node. Use an nginx reverse proxy for your html/js/css assets.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#17With regards to Vert.x, it seems like really cool stuff. On the blog post about version 1 being released it mentions being able to mix and match several programming languages. Does this mean you can use different libraries written in different languages in the same Vert.x server?
Yes indeed. You can mix and match Java, JavaScript, Ruby and Groovy in the same app.
We hope to support more languages going ahead (e.g. Java, Scala, ...)
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#18Quite interesting. Is the Vert.x API compatible with CommonJS and/or Node modules? If not, I think it will suffer from the same chicken/egg problem that WebOS had with apps.
Agreed, it would be good to have CommonJS support.
However, it's unlikely that node modules will work as is with Vert.x, since the API is different. (Unless someone writes a translation layer)
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#19Yet another meaningless micro benchmark. There is no point in measuring a hello world http request in one framework vs. another. There should be a larger application that even remotely resembles some kind of real world usage. Maybe some day we'll have some kind of a "standard" for a web framework benchmark, an application that actually does something so it's worth benchmarking.
I'd upvote this more than once if I could. The beauty and efficiency of a web framework must be measured as a trade off between the amount of instructions executed to check for corner cases etc. Anyone could write a framework that executes hello world faster than a popular one if they just assume for instance that no one will ever make a POST request or use a query string. That wouldn't be a very useful framework, but it could definitely execute GET '/' fast.
Re: Vert.x (JVM async) vs Node.js Http benchmarks results
#20[deleted]