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

181–190 of 241 posts

Re: Web Framework Benchmarks Round 2

#181

Post by brass9 »

columbo wrote: post #94
milesf wrote: post #61

It's a useful data point to know the speed of frameworks, but what matters most to me is speed of development and whether or not I enjoy the process. Wish there was a way to benchmark those points.

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

Do you really have any experience developing any real-world project on these disparate frameworks?

Re: Web Framework Benchmarks Round 2

#182

Post by tracker1 »

Where's the source for the implementations? Of interest to me is the NodeJS instances.. was this single-process, or multi-process via cluster (which is recommended for higher performance). The only source I saw was for the testing framework.

--- edit: found it. https://github.com/TechEmpower/FrameworkBenchmarks

Seems to be using cluster. I'm not surprised that Go and servlets were faster... just surprised to see NodeJS in the middle of the pack position. Though performance isn't the only reason I really like NodeJS

Re: Web Framework Benchmarks Round 2

#184

Post by just2n »

Once again, the Node examples are wrong.

- Unnecessary parsing.

- Writing strings instead of buffers (they're copied, they aren't sent as-is).

- Using async. It does a lot of really nasty things, most of which break V8 optimization best practices. This is a perf benchmark, not a comparison of how concise your code can be.

- Having the main request handler in a gigantic function that will never be properly optimized by V8.

- Not getting helper functions that are clearly monomorphic warm before accepting requests.

While the code itself is what I would consider fine, when benchmarking against strongly typed compiled languages, performance concerns become important, even if you have to write ugly code.

Re: Web Framework Benchmarks Round 2

#185

Post by kaoD »

just2n wrote: post #184

Once again, the Node examples are wrong. - Unnecessary parsing. - Writing strings instead of buffers (they're copied, they aren't sent as-is). - Using async. It does a lot of really nasty things, most of which break V8 optimization best practices. This is a perf benchmark, not a comparison of how concise your code can be. - Having the main request handler in a gigantic function that will never be properly optimized b…

On the one hand, you're completely right.

On the other hand, shouldn't real code be tested? How accurate would a ugly-optimized-code be when you SHOULD write reusable code in your real life projects?

Re: Web Framework Benchmarks Round 2

#187

Post by tracker1 »

errnoh wrote: post #166
DonnyV wrote: post #101

Earlier quoted context omitted.

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)

I'd be curious how it would perform on C# (windows/.net vs. linux/mono) .. though the environment setup would probably be a bit more involved.. and IIS is a very different beast.

I'd think that it would probably land somewhere close to Java Servlets, but a bit slower. The framework stack for web requests in .Net is probably a bit more than it is in the servlet server in question. I would also think that Mono would be a bit slower than IIS, only because IIS does very well at pooling resources/threads for multiple requests.

There's also the question of async .Net handling vs. blocking. Most .Net code I've seen is blocking, but there are async options, and as of the 4.x releases are much easier to use.

Re: Web Framework Benchmarks Round 2

#188

Post by Zak »

cygwin98 wrote: post #105
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.

The performance of Compojure was really impressive, which was almost three times as fast as play-scala. I was expecting the opposite, considering that Scala is generally a bit faster than Clojure.

From what little I know about Play, it does a lot more than Compojure does. Compojure is really just a routing library. This is a benchmark of Ring (HTTP communication), Compojure (routing), Korma (database access/abstraction) and Cheshire (JSON serialization). I'm pretty sure a basic request in Play goes through more middleware than that.

But yes, the performance of a reasonable web app stack on Clojure is very good.

Re: Web Framework Benchmarks Round 2

#189

Post by just2n »

kaoD wrote: post #185
just2n wrote: post #184

Once again, the Node examples are wrong. - Unnecessary parsing. - Writing strings instead of buffers (they're copied, they aren't sent as-is). - Using async. It does a lot of really nasty things, most of which break V8 optimization best practices. This is a perf benchmark, not a comparison of how concise your code can be. - Having the main request handler in a gigantic function that will never be properly optimized b…

On the one hand, you're completely right. On the other hand, shouldn't real code be tested? How accurate would a ugly-optimized-code be when you SHOULD write reusable code in your real life projects?

I wouldn't use async myself, so what's "real" code varies from person to person. This is why benchmarks like this are highly misleading.

But ideally, yes. We'd be better informed to see how real world code performs rather than some idyllic perf-oriented creature.

Re: Web Framework Benchmarks Round 2

#190

Post by rufugee »

elechi wrote: post #178
rufugee wrote: post #174

Earlier quoted context omitted.

I should also say: putting together a new screen (form or otherwise) in Vaadin is extremely fast. It's the fastest I've ever been able to develop web-based UIs, simply because all I'm forced to think about is Java.

I see. I found it to be a little difficult in terms of dealing with data, especially messing around with the Table object. Best of luck to your project.

The JPAContainer and SQLContainer it provides makes this reasonably easy.
Post reply on HN