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

Web Framework Benchmarks Round 4

techempower.com

Post reply on HN
Print view View original

231–240 of 358 posts

Re: Web Framework Benchmarks Round 4

#231

Post by landr0id »

zenlikethat wrote: post #193
landr0id wrote: post #163

Earlier quoted context omitted.

While we're on the subject... Has anyone tried out Revel[.]? If so, what are your thoughts on it? [.] https://github.com/robfig/revel

(Disclaimer: I'm pretty new to Go). I tried Revel out a little while ago, and found it awesome at first. It felt like it could have the potential to dramatically speed up the development of Go web apps. I like the server and hotswapping features a lot, for instance. But at the moment unfortunately I don't think it's very mature. Support for interacting with the DB, arguably the most important part of a web applicatio…

I've been meaning to get one of the examples setup and just play around with it. To be perfectly honest I'm relatively new to the world of databases and such (I've been using RoR for some projects if that explains why), so tackling that gorp will be another awesome learning experience. Thanks!

Re: Web Framework Benchmarks Round 4

#232

Post by Joeri »

showerst wrote: post #77
krg wrote: post #48

Earlier quoted context omitted.

Raw PHP (with no framework, no ORM) does well in the 20 query test, but unfortunately you have to go down pretty far before any of the PHP frameworks show up on that list. If I filter to just show PHP, the 20 query test shows that the first framework is less than 50% the performance of raw PHP.

Looking into the code, the raw PHP is using PDO with persistent connections, and I'm not sure that's turned on in any of the frameworks. It looks like it's off by default in Redbean at least. No idea if this makes a big difference, I haven't had time to try it out.

Yes, it does look like none of the frameworks are using persistent connections, which would explain the horrible performance. To be fair though, it is still a valid measurement if the frameworks don't enable persistent connections by default.

Re: Web Framework Benchmarks Round 4

#233

Post by laumars »

voidlogic wrote: post #225
kbenson wrote: post #175

Earlier quoted context omitted.

I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. Not sure yet if there are smaller ones (note that there are no other files required for those apps, period) In the same vein, Lua's OpenResty[4] looks good, as do Tornado[5], Flask[6] and Bottle[7] (although you need to tease the raw/ORM methods apart to get an idea for the last two). And of c…

>>I don't consider the Go size pretty small. You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). Also, Go is statically typed = win

> Also, Go is statically typed = win

Actually I find Perl's type system to make the most sense for web work:

1) Any zero length string or 0 valued int is classed as false, which is handy when checking the returns from query strings et al.

2) You can use eq for string comparison or == for numeric checking, which means which is handy has you can read values from a query string and then compare it against an int without having to do type conversion.

Don't get me wrong, I don't have anything against statically typed languages - in fact I normally prefer them. But the way Perl does type checking I find reduces the number of type problems when dealing with web development.

That all said, I much prefer working with structured types in Go than in Perl.

Re: Web Framework Benchmarks Round 4

#234

Post by voidlogic »

exabrial wrote: post #173
hippich wrote: post #57

Whenever I hear "Java" I also get association "slow". But looking into this list - java web frameworks doing incredible job!

Check out the graphs on the "benchmark game": http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... The JVM indeed kicks some major butt.

You should link quad 64 rather than uni 32 as it is much more real-world applicable. That being said, it doesn't change the fact you are stating here.

Re: Web Framework Benchmarks Round 4

#235

Post by cmircea »

voidlogic wrote: post #50
cmircea wrote: post #27

Earlier quoted context omitted.

Would it be too much to ask to also run a Windows VM? Or use Mono?

Linux amd64 is the dominate internet serving platform; supporting a non-free OS for the benefit of a single test entry seems dumb. I'm all for a Mono entry however.

Linux may be the dominant platform, but that doesn't mean Windows doesn't have a very significant share either: http://w3techs.com/technologies/overview/operating_system/al...

Re: Web Framework Benchmarks Round 4

#236

Post by voidlogic »

bhauer wrote: post #160
buster wrote: post #156

It'd be nice to also have a "lines of code" comparison, because i can see how some benchmarks are at the top but after looking at the code they also tend to be quite "manual".

We do plan to start tackling that other dimension, efficiency. Source lines of code is one objective measure that, for all its faults, we plan to include. In a previous round, I pasted the relevant code directly into the results view. I will likely do that again soon since it's convenient for the reader. For the time being, I invite you to browse the Github repository and examine the test implementation source.

gzipped source size in generally considered a better measure of effort than actual LOC. The reason for this is that the languages with a lot of boiler plate usually have tooling, IDE's etc to make that pain go away, and gzipped source, while still counting repeated boiler plate end up weighing it less than unique lines of code.

Re: Web Framework Benchmarks Round 4

#237

Post by corresation »

just2n wrote: post #169

Before looking at the benchmark results, I took a glance at the Node source and I expected it to perform worse than it did previously. It does almost universally. Not only haven't the glaring perf issues remained since round 1, it's added more. In the real world, when you look at a metric that says your req/s is a bottleneck, which is what this benchmark is loosely simulating, you'd fix it. You wouldn't just say "nop…

I still don't find these benchmarks very useful.

Says someone (many someones) about every benchmark, ever. I've never seen a benchmark that yields universal praise, every one earning criticism from people who don't like the results.

What is the value of a framework? Is it speed?

This is clearly a benchmark of performance. Is that the single value of a framework? Of course it isn't. But you certainly shouldn't stick your head in the sand about it.

Re: Web Framework Benchmarks Round 4

#238

Post by cmircea »

zinxq wrote: post #178

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the t…

To add my 2 cents, static languages have started adding dynamic features. One example is C#.

Re: Web Framework Benchmarks Round 4

#239

Post by laumars »

bhauer wrote: post #2

This is the most recent update to our ongoing project measuring the performance of web application platforms and frameworks. In this round we've received several more community-contributed tests in Perl, PHP, Python, Java, and JavaScript. Go is a comeback champion thanks to changes made by Brad Fitzpatrick [1] and others in the Go community. A new "Fortunes" test was also added (implemented in 17 of the frameworks) t…

There's two main mysql drivers for Go mymysql and go-mysql-driver. I've found the concurrency performance of the former to be abysmal when doing my benchmarking. Then the moment I switched to the latter, Go's performance went through the roof.
Post reply on HN