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

Web Framework Benchmarks

techempower.com

Post reply on HN
Print view View original

341–350 of 415 posts

Re: Web Framework Benchmarks

#341

Post by codewright »

bradrydzewski wrote: post #258
jondot wrote: post #26

Earlier quoted context omitted.

I think this is a much needed and excellent point to make. Just take a look at how Go dips down when using Webgo.

I used Go's benchmarking tool to compare raw routing performance of various frameworks. The handlers all return a simple "Hello World" string. Here are the results: PASS Benchmark_Routes 100000 13945 ns/op Benchmark_Pat 500000 6068 ns/op Benchmark_GorillaHandler 200000 11042 ns/op Benchmark_Webgo 100000 26350 ns/op ok github.com/bradrydzewski/routes/bench 12.605s I then ran the same benchmark, but this time I modifie…

By the way:

https://plus.google.com/u/0/115863474911002159675/posts/L3o9...

More SPEEEEEEEEEEEEED coming down the pipe in 1.1 for Go's net/http. :)

Re: Web Framework Benchmarks

#342

Post by abalone »

kclay wrote: post #161
bhauer wrote: post #92

Earlier quoted context omitted.

It's funny you should put this together because in an earlier draft of this blog entry I had created a tongue-in-cheek unit to express the average cost per additional line of code. Based on our Cake PHP numbers, I wanted to describe PHP as having the highest average cost per line of code. But we dropped this because I felt it ultimately wasn't fair to say that based on the limited data we had and it could be easily i…

I'm pretty shocked that Play scored so low. One would think that being built on netty would put Play in a higher rank. Database access for sure needs to be in async block

It's not just the DB test. The JSON test was way slower than Netty, too.

Re: Web Framework Benchmarks

#343

Post by abalone »

jholla14 wrote: post #195
goodwink wrote: post #86

Earlier quoted context omitted.

These could probably be further broken down into micro-frameworks (like Express, Sinatra, Vert.x etc.) and large MVC frameworks (like Play and Rails). Gemini is sort of an outlier that doesn't really fit either category well, but the micro-frameworks have a fairly consistently higher framework optimization index than the large MVC frameworks which is as expected. Express and Sinatra really stand out as widely-used, v…

The play test was written totally incorrectly since it used blocking database calls. Since play is really just a layer on top of Netty it should perform nearly as well if correctly written.

But Play's trivial JSON test was much slower than Netty's.

Re: Web Framework Benchmarks

#344

Post by sharedliberty »

bhauer wrote: post #322
greenlaw110 wrote: post #290

Why Play benchmark is running on Resin? Shouldn't it be directly on top of Netty?

Play is not running on Resin. Did we accidentally say that somewhere? If so, we'll correct it.

Here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...

The tests were run with:

Java OpenJDK 1.7.0_09 Resin 4.0.34 Play 2.1.0

Re: Web Framework Benchmarks

#345

Post by abalone »

mark242 wrote: post #219
kainsavage wrote: post #64

Earlier quoted context omitted.

It is probably worth noting that while we strive to make the tests as fair as possible, we followed the official tutorials for each framework when building out the tests but we fully expect there to be small instances where minor tweaks improve a given test. Given that I am no Play expert, it would be of great value to have one who is (and it sounds like you could lend a hand there) to check out the code on the githu…

There are a few problems with your Play code that are causing it to be unnecessarily slow. First-- what you're really testing here is the Jackson library. A majority of the cycles used in your application are being burned in that toJson call of an array of objects. This isn't a fair test compared to the servlet implementation because you're calling Jackson against a map in the Play example, versus against a simple St…

Not sure if your theory can really account for the 7X difference between Play and Netty in the JSON test. They both create a trivial name/value pair and pass it to the JSON serializer. In Play's case, it gets passed to their Jerkson wrapper for Jackson. What would you even change about that code?

(Note: I'm not necessarily saying the Jerkson wrapper is the culprit. Could be Play's routing framework, or something else.)

Re: Web Framework Benchmarks

#346

Post by abalone »

jfim wrote: post #130
eweise wrote: post #124

Was Play 1 or Play 2 tested? I thought Play ran on Netty so I'm surprised it didn't fair better.

They're using Play 2.1 with Java, without using futures for database queries. Not sure how representative of real usage that would be, though.

But the JSON test was 7X slower too.

Re: Web Framework Benchmarks

#348

Post by mootothemax »

sergiosgc wrote: post #310
mootothemax wrote: post #139

Earlier quoted context omitted.

How is it broken? All data is returned as an associative array, so there is no way to call something like: $cows = $this->Cows->findByStatus(COW_STATUS_NOT_MOOING); foreach($cows as $cow) { $cow->moo(); } But that's pretty minor. The big issue is: all data is returned as an associate array ! There is no lazy-loading of the data as you e.g. seek through it, which means it's very easy for people to pass around huge arr…

I don't use Cake, so don't read this is a defence of Cake. Lazy loading seems to me a kludge trying to fix poor SQL querying. If you can filter at the app layer, why not pass the information down and filter at the DB layer? You'll be transferring less data and may even read less data from disk (with proper indexes)

Lazy loading seems to me a kludge trying to fix poor SQL querying.

I very much agree with you, lazy loading should not be used as substitute for only querying and/or filtering the data you actually need.

However, there's always going to be a minimum; eventually, the data needs to be processed or displayed! Why load all of it immediately into memory (and potentially pass that around), rather than when it's actually needed?

I think of it a bit like using pointers; passing around the location of the data, rather than the data itself, makes life good for all concerned.

I don't use Cake, so don't read this is a defence of Cake.

Thanks for the disclaimer, as I'm guessing you've experienced before, it's all too easy to get into accidental flamewars about this stuff :)

Re: Web Framework Benchmarks

#349

Post by johnx123-up »

wyck wrote: post #199
bhauer wrote: post #61

Earlier quoted context omitted.

That would be fantastic. Get in touch with pfalls on Github and he can give you the information. It's fairly simple.

+1 this would be interesting given that there are a lot of PHP frameworks besides cake, namely. Silex/Symfony2 Yii Zend Kohana Fuel Laravel

I'll be happy to see benchmarks with PHP frameworks written as a C extension: 1. Yaf PHP http://www.yafdev.com/ , 2. PHP-ActiveRecord++ https://github.com/roeitell/php-activerecord-plusplus
Post reply on HN