so Java is fastest... then why does it seem that in the real world Java web apps are slowest?
Can you name some examples?
Web Framework Benchmarks Round 5
41–50 of 58 posts
Re: Web Framework Benchmarks Round 5
#42What I miss from that benchmark:
- CPU/memory consumption
- higher concurrency level (4096 for i7 at least)
- dependency graphs - latency/concurrency etc.
Re: Web Framework Benchmarks Round 5
#43What I miss from that benchmark: - CPU/memory consumption - higher concurrency level (4096 for i7 at least) - dependency graphs - latency/concurrency etc.
Agreed, this would be interesting. It's under discussion: https://github.com/TechEmpower/FrameworkBenchmarks/issues/10...
Re: Web Framework Benchmarks Round 5
#44I still miss the async sinatra there. I've done some work on that but don't have enough time to finish it. - https://github.com/mikz/FrameworkBenchmarks/commit/2140775e1... the one thread issue is main problem of all ruby benchmarks there
We'd like to include Async Sinatra, but I don't want to rush you. We look forward to the pull request when you find the time to wrap it up.
Re: Web Framework Benchmarks Round 5
#45INB4 questions to the Go results: Nope, issues of round 4 not addressed yet.
Like in round 4 (since the related code hasn't changed) the many concurrent spawned goroutines probably get in each others way, causing a high latency and low throughput.
There was a reversion of the test without goroutines, which I think performed better. But I was told the goroutines version is more realistic... (I don't share this opinion).
To be fair, this version had also a manual connection pool to address a previous bug.
Also Go's database connectivity is not very mature yet. There is still a lot of work to do. I'm pretty sure it can and will be done.
Re: Web Framework Benchmarks Round 5
#46Earlier quoted context omitted.
It would be even more ( much more? ) effective to use preconfigured https://github.com/chaoslawful/drizzle-nginx-module location and 'ngx.location.capture' I suppose And http://leafo.net/lapis/ is missing again.
I benchmarked the pure postgresql lua driver to be ˜3 times as fast as the nginx-postgresql-c driver. When you use the nginx drivers from a lua context you have to use an internal nginx request to that location, so there's some overhead. If you want to improve even further on the lua drivers, LuaJIT FFI is probably the right answer.
>˜3 times as fast as the nginx-postgresql-c driver
That's interesting..
>LuaJIT FFI is probably the right answer
Do you mean calling nginx internal functions (DB driver or location capture, like ngx_eval module does in that case) via FFI (I doubt if that is safe in any way) or just use libpq from LuaJIT directly?
Re: Web Framework Benchmarks Round 5
#47What I miss from that benchmark: - CPU/memory consumption - higher concurrency level (4096 for i7 at least) - dependency graphs - latency/concurrency etc.
Agreed, this would be interesting. It's under discussion: https://github.com/TechEmpower/FrameworkBenchmarks/issues/10...
Nice! I hope we will see it in next rounds.
There is a big difference between "it serves 1200 rps" and "it serves 1200 rps and barely seen in top" actually
Re: Web Framework Benchmarks Round 5
#48Earlier quoted context omitted.
I benchmarked the pure postgresql lua driver to be ˜3 times as fast as the nginx-postgresql-c driver. When you use the nginx drivers from a lua context you have to use an internal nginx request to that location, so there's some overhead. If you want to improve even further on the lua drivers, LuaJIT FFI is probably the right answer.
> ˜3 times as fast as the nginx-postgresql-c driver That's interesting.. > LuaJIT FFI is probably the right answer Do you mean calling nginx internal functions (DB driver or location capture, like ngx_eval module does in that case) via FFI (I doubt if that is safe in any way) or just use libpq from LuaJIT directly?
I haven't benchmarked the mysql drivers, so results might be different there.
There's some work being done by openresty author w.r.t. ffi for openresty itself, it might yield interesting results. And yes, I think both the option you listed are viable. But the lua drivers already perform very well.
Re: Web Framework Benchmarks Round 5
#49so Java is fastest... then why does it seem that in the real world Java web apps are slowest?
Assuming you are talking about web applications from banks and non-tech Fortune 500 in general, it's because many of them are:
* incredibly bloated (and still lack most of the features
that an actual human user would want)
* poorly coded by armies of outsourced programmers
* using over-engineered code built on top of obsolete frameworks
* running on a "homologated" stack, which is often 3 to 7 years out-of-date
Re: Web Framework Benchmarks Round 5
#50INB4 questions to the Go results: Nope, issues of round 4 not addressed yet. Like in round 4 (since the related code hasn't changed) the many concurrent spawned goroutines probably get in each others way, causing a high latency and low throughput. There was a reversion of the test without goroutines, which I think performed better. But I was told the goroutines version is more realistic... (I don't share this opinion…
Hi Julien,
Thanks for the note. I'd like to get to the bottom of this and make the Go test representative of best practices. A previous decision may have been made to favor an implementation that was measured to be faster at the expense of best practices [1], but that is not irreversible.
I am not a Go expert and I believe you are, and certainly @bradfitz is as well. If you two tell us definitively to change the Go implementation to better comply with best practices, I'll see that it's done for Round 6. I apologize if you feel we stepped on your opinions in any fashion. I really value your input in the project to date and hope it will continue.
[1] https://github.com/TechEmpower/FrameworkBenchmarks/pull/209