Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Framework Benchmarks Round 2

techempower.com

Post reply on HN
Print view View original

161–170 of 241 posts

Re: Web Framework Benchmarks Round 2

#161

Post by jamesaguilar »

superuser2 wrote: post #106
columbo wrote: post #94

Earlier quoted context omitted.

>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important…

Performant, not scalable. You can throw money at Rails and it will handle the load, but it would cost a lot more.

If budget is finite, performant ~= scalable once you get to the point where you're actually trying to scale.

Re: Web Framework Benchmarks Round 2

#162

Post by errnoh »

cmsimike wrote: post #9
voidlogic wrote: post #6

It is worth pointing out Go 1.0.3 not Go 1.1 beta is being used. I tested the code locally and on my machine 1.1 beta was about 20% "faster" (req/sec).

Really? We're definitely going to try that out!

Yeah, 20% is even quite low estimate. Here's 1.0.3 vs 1.1 from just now (request worker (wrk) and Go http server running in separate machines)

https://gist.github.com/errnoh/5320784

Re: Web Framework Benchmarks Round 2

#163

Post by [deleted] »

wyqueshocec wrote: post #121
columbo wrote: post #94

Earlier quoted context omitted.

>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important…

From my experience, the Spring one would take 10x as long to make, which means more developer cost and more feedback reaction time. Certainly not a deal breaker, but a cost/tradeoff one must consider. Edit: clarity.

[deleted]

Re: Web Framework Benchmarks Round 2

#164

Post by rufugee »

wyqueshocec wrote: post #121
columbo wrote: post #94

Earlier quoted context omitted.

>what matters most to me is speed of development and whether or not I enjoy the process. Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important…

From my experience, the Spring one would take 10x as long to make, which means more developer cost and more feedback reaction time. Certainly not a deal breaker, but a cost/tradeoff one must consider. Edit: clarity.

As someone who recently came back to Java from a 5 year stint with Rails, I can safely say this is not true by any stretch of the imagination. If you stick to those tools in the Java ecosystem which meet your requirements, you can be incredibly productive.

The problem is that the Java world is full of over-engineered solutions which are really targeted at extremely large enterprise applications surrounded by a community of folks who like to menturbate about them. As a startup, you don't need to focus on those solutions. You'll not need 99% of them.

However, you can choose bit and pieces. I'm using Vaadin, JPA and Guice and finding it incredibly productive and am able to deliver functionality in far less time than it took me in Rails. I'm not using 90% of the Java EE stack, but it's available to me if/when I need it.

Rails was a great thing for the software development world. It drove convention over configuration and caused a lot of the competing technologies to pause and question why things were the way they were. But IMHO, managing the whole Rails stack (rails + coffeescript + css in our case) across a group of people became a chore. YMMV, but the statically-typed nature of Java along with the very capable technology stacks you can assemble have eased our daily jobs tremendously.

Re: Web Framework Benchmarks Round 2

#166

Post by errnoh »

DonnyV wrote: post #101
bhauer wrote: post #2

This is our first follow up to last week's web framework benchmarks. Since last week, we have received dozens of comments, thoughts, questions, criticisms, and most importantly pull requests. This post shows data collected from a second run on EC2 and i7 hardware that started on Tuesday of this week. A third round with even more community contribution is already underway. Thanks especially to those who have contribut…

Why no .NET C# and Mono?

Their repo at https://github.com/TechEmpower/FrameworkBenchmarks is open for pull requests

I don't think they have anything against C#, probably no one just has committed C# version to be benched.

(edit: whops, linked fork first)

Re: Web Framework Benchmarks Round 2

#167

Post by doktrin »

mdlthree wrote: post #157
doktrin wrote: post #129

Earlier quoted context omitted.

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 tha…

Understandable, but I would offer a counterpoint.

When it comes to "learning" frameworks, I don't think the highest level of abstraction is necessarily the best. Some are better able to cope with black-box behavior than others. For those who feel the need to understand their tools as they use them, I'm of the view that the Sinatras of the world are a better starting point.

Re: Web Framework Benchmarks Round 2

#168

Post by giulianob »

resu_nimda wrote: post #76
giulianob wrote: post #16

Earlier quoted context omitted.

Did you guys turn on byte code caching for all the PHP frameworks? If not, then I recommend everyone ignore these benchmarks until that is completely done.

So, they've put a ton of effort into this, have been very receptive to community feedback and criticism, and have followed through with a major update to the whole thing. And then you come in with a drive-by recommendation for everyone to ignore the whole thing because of your unfounded and incorrect assumption. Nice work.

I said that because it was the case with the first version of the benchmark.

Re: Web Framework Benchmarks Round 2

#169

Post by Zak »

krg wrote: post #112
Zak wrote: post #88

A note about Compojure: they're using Korma for database access. Korma is an abstraction layer that's more Clojure-friendly than using SQL directly, but lighter than an ORM. Using clojure.java.jdbc might produce higher performance.

Where possible on the tests, we tried to use something other than raw SQL because we wouldn't expect someone to use raw SQL everywhere when writing a real application. We chose Korma because it seemed decently popular for Clojure, but we're certainly open to a "compojure-raw" test that uses clojure/java.jdbc. Feel free to submit a pull request. :)

I'm not saying Korma isn't a good or realistic choice. I use it myself. There did seem to be some disagreement in freenode #clojure about whether that was the best way to go, or JDBC and prepared statements. Evidently, a lot of people actually do like SQL.

It's just important for people to be aware that "Compojure" actually represents "one possible production-ready stack that uses Compojure as the routing component", as do several other items on the list. I don't mean that as a criticism - just clarification.

Re: Web Framework Benchmarks Round 2

#170

Post by the_mitsuhiko »

superuser2 wrote: post #115
the_mitsuhiko wrote: post #99

Earlier quoted context omitted.

> Flask I don't know about Sinatra or anything else but I can give you the reason why Flask out of the box performs like it does. Unlike PHP Flask is threadsafe and uses locks and thread or greenlet local storage. This level of indirection adds a basic performance penalty when executed on a single threaded server like gunicorn. There are ways to change that if you think that becomes a performance problem by replacing…

But the other database tests were run against the same DB server and configuration. How can Flask's performance be the DB's fault?

> But the other database tests were run against the same DB server and configuration. How can Flask's performance be the DB's fault?

They are written against the core database layer or the framework (in case of Django the Django ORM) and in case of Flask: Flask-SQLAlchemy. The default config of both of these things is to not pool connections. That is not true for all other frameworks.

Also I'm not blaming anything here, just pointing out that there are differences in the setup.

Post reply on HN