Gemini conveniently leads the pack all the time. So either OP and his/her colleagues have revolutionized web programming or the benchmark is nothing but a PR piece.
Web Framework Benchmarks Round 2
151–160 of 241 posts
Re: Web Framework Benchmarks Round 2
#152I code in Ruby, Python and Groovy/Grails. I'm amazed that Grails performs so much better than the others.
I guess that's one of the big advantages JVM languages have. Using stuff like Spring or Hibernate (like Grails does), you benefit from thousands of person-hours spent on tuning those libraries and you still get native Java performance.
Obviously there's a price you have to pay for all the things Grails built on top of Spring/Hibernate (in the benchmark it looks like Grails' performance = Spring / 2), but in general, it's still faster than just writing everything in Groovy (Ruby, Python, ...).
Re: Web Framework Benchmarks Round 2
#153I think that the play-java one would likely benefit greatly from using raw jdbc rather than the ebean ORM. In fact my best guess is this is why the scala/java versions are so far apart. In past projects, scrapping ebean always led to large performance improvements in throughput, etc.
https://news.ycombinator.com/item?id=5499839
ps: i agree that raw jdbc would enhance the performance.
Re: Web Framework Benchmarks Round 2
#154Gemini conveniently leads the pack all the time. So either OP and his/her colleagues have revolutionized web programming or the benchmark is nothing but a PR piece.
Just ignore Gemini. In fact, you can click the "hide" link on the charts to remove it.
From our first benchmarks post: http://www.techempower.com/blog/2013/03/28/framework-benchma... "Why include this Gemini framework I've never heard of?" We have included our in-house Java web framework, Gemini, in our tests. We've done so because it's of interest to us. You can consider it a stand-in for any relatively lightweight minimal-locking Java framework. While we're proud of how it performs among the well-established field, this exercise is not about Gemini. We routinely use other frameworks on client projects and we want this data to inform our recommendations for new projects.
Re: Web Framework Benchmarks Round 2
#155Is gemini really that awesome? Why arent more people talking about it?
Gemini is closed source. The company running these comparisons is the only team that is qualified to test/develop with it.
While it is true that our source code is closed at the moment, you are still free to check out the benchmark code from github and run it yourself to verify our results.
It wouldn't really be a fair test if we put all these frameworks up for testing, suggested Gemini was better than sliced bread with auto-applying jam, and didn't back it up in a testable way ;-)
Re: Web Framework Benchmarks Round 2
#156Earlier quoted context omitted.
My best guess is that the java one is slow due to ebean (I've always seen huge performance improvements from switching to raw jdbc). The scala one I have no clue.
More likely because the version uses only as many threads as the cpu has cores. Whereas the servlet version for example has 128 thanks to the default resin configuration.
That would definitely be an issue as well. Although, this is easily configurable within the application.conf file if I remember correctly.
Re: Web Framework Benchmarks Round 2
#157As an amateur hacker and after 275 days of reading Hacker News I feel I can now navigate in the sea of client side Javascript frameworks. With the introduction of this data on web framework performance, I now have another set of choices that I am completely unqualified to comprehend. My first impression is that this data shows about 3 levels of web frameworks. At the bottom (slowest) we have Django's and Rails and ma…
I think it's a misconception to think of Django and Rails as "introductory frameworks". These are production ready frameworks that can scale to meet a variety of (though not all) business needs.
My intention of the word introductory was not to feel like training wheels. Joeri in this thread says:
>>You have to trade off developer productivity for performance when it comes to choosing frameworks. The slower the framework the more it does for you.
And in that respect, the more the framework does for a developer, the better it is probably suited a starting point for new developers. It is a badge of success that Django and Rails can be able to serve a whole spectrum of needs.
Re: Web Framework Benchmarks Round 2
#158Earlier quoted context omitted.
Not sure about ruby, but django doesn't ship with connection pooling, so that is probably why its database performance is terrible. It could be configured to use pooling. With such a trivial request handler like the one in benchmark, only a small percentage of the execution is actually taken up in the view, so all of the time you're seeing in the benchmark is pure overhead of the framework. A longer running view acro…
Correct, because we chose MySQL as the database backend, both Django and Flask are punished for not having a connection pool. We've received requests to do the test using Postgres which does have a connection pool, and we hope to eventually get to that.
What are your using for db access? If you are using SQLAlchemy or Flask-SQLAlchemy, that should automatically do connection pooling.
Re: Web Framework Benchmarks Round 2
#159Earlier quoted context omitted.
Having max/min spare servers as the same amount is a bad idea. This is incurs a substantial amount of process swapping, as every single request php-fpm is going to try and ensure there are precisely 256 idle servers.
Ok, help us out: Given that we have Wrk set to max out at 256 concurrent requests, what would the ideal tuning for php-fpm? A pull request would be ideal, but you can also just tell us. :)
I'd set minimum idle to something like 16 or 32. php-fpm will not create more than 32 workers/sec.
What happens now is 256 workers running and 256 simultaneous requests occur. So php-fpm sees 256 workers busy, 0 idle. The minimum idle is 256, so it attempts to start 256 additional processes.
Re: Web Framework Benchmarks Round 2
#160Is anyone else alarmed to see raw PHP spanking Flask, Sinatra, and other Python/Ruby frameworks? If not, can anyone explain in layman's terms why that should be the case?
Why shouldn't that be the case? PHP has been designed from the get go to be super fast and 5.4 introduced a bunch of optimizations that have sped it up even more so. Ruby was designed for programmer happiness, PHP was designed for performance and getting sh*t done.
> PHP has been designed from the get go to be super fast
PHP was never designed to be fast. As far as execution speed goes, PHP will be in the same ballpark as Perl?Python/Ruby. PHP comes up as faster in these tests because of all the extra things the frameworks are doing. See the_mitsuhiko comment above regarding flask for an example.