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

101–110 of 415 posts

Re: Web Framework Benchmarks

#101

Post by pekk »

systematical wrote: post #93

These are some brutal results for CakePHP (which I use). However, in practice no intermediate developer would be issuing queries like that in a loop. They would loop through a set of data, building a IN statement example: WHERE field IN ('x','y','z'). Thus only sending a single query to the database. Still, the Cake developers really need to improve the speed of their framework.

I keep seeing numbers like this in benchmarks over the last few years, it would be great to see CakePHP's numbers "rehabilitated" using techniques like you discuss.

Re: Web Framework Benchmarks

#102

Post by voidlogic »

goodwink wrote: post #88
voidlogic wrote: post #63

Earlier quoted context omitted.

Webgo... I'll stick with "net/http" and Gorilla thanks. Also, They used Go 1.0.3... I hope they update to 1.1 next month. Most everyone using Go for intensive production uses is using Go tip (which is the branch due to become 1.1 RC next month)

Wow, directly on tip? That seems to speak very highly of the day-to-day development stability of Go.

A good tip build tends to be more stable then 1.0.3 and has hugely improved performance (most importantly for large application in garbage collection and generation).

To select a suitable tip build we use http://build.golang.org/ and https://groups.google.com/forum/?fromgroups#!forum/golang-de... . My recommendation would be to find a one or two week old build that passed all checks, do a quick skim of the mailing list to make sure there weren't any other issues and use that revision. Also, you will see some the the builders are broken-

Of course if your application has automated unit tests and load tests, run those too before a full deployment.

Re: Web Framework Benchmarks

#103

Post by systematical »

pekk wrote: post #101
systematical wrote: post #93

These are some brutal results for CakePHP (which I use). However, in practice no intermediate developer would be issuing queries like that in a loop. They would loop through a set of data, building a IN statement example: WHERE field IN ('x','y','z'). Thus only sending a single query to the database. Still, the Cake developers really need to improve the speed of their framework.

I keep seeing numbers like this in benchmarks over the last few years, it would be great to see CakePHP's numbers "rehabilitated" using techniques like you discuss.

It's a fair way of testing, its just not the way a developer would write it in practice. Clearly disregards the "Big O".

Re: Web Framework Benchmarks

#104

Post by kainsavage »

Kiro wrote: post #6

So this means I should stop using CakePHP?

Obviously, the data should not steer you towards rewriting applications using a different framework. Really, it should just show as another metric to help deciding which framework is best suited for your needs. If you plan on writing up a blog application for yourself and you might get 100 concurrent users, then you could use CakePHP for the sake of familiarity. Then again, if you are trying to write the next Twitter and have the requirement of needing to be able to service 20,000 concurrent requests, then I would say "yes, this means you should stop using CakePHP."

Re: Web Framework Benchmarks

#105

Post by bhauer »

pekk wrote: post #96

Numerous irregularities plus a strong vested interest in the JVM make me doubt they have given adequate shrift to Go, here. Given the amount of interest in Haskell and Yesod around here, it is strange that it is missing.

We love Go here! But admittedly, we have not yet deployed an actual Go web application to a production environment, so the tests demonstrate our first attempt at creating a Go production environment. We based the approach on whatever material we could find on Go reference sites.

That said, we'd love to hear what we did wrong in the Go tests so that we can fix those up.

We'll be posting follow ups as we've had a chance to go through all the recommended tweaks.

Re: Web Framework Benchmarks

#106

Post by voidlogic »

pfalls wrote: post #82
voidlogic wrote: post #63

Earlier quoted context omitted.

Webgo... I'll stick with "net/http" and Gorilla thanks. Also, They used Go 1.0.3... I hope they update to 1.1 next month. Most everyone using Go for intensive production uses is using Go tip (which is the branch due to become 1.1 RC next month)

This is great to know, we were hesitant to use non-stable versions (although we were forced to in certain cases), but knowing that it's what is common practice for production environments would change our minds.

We switched to using tip after several Go core devs recommended that move to us, the folks on go-nuts IRC agreed and we tested it and found it to be more stable than 1.0.3

Re: Web Framework Benchmarks

#107

Post by grey-area »

jondot wrote: post #26
goodwink wrote: post #21

One of the most interesting things this comparison brings out to me is not so much the differences between the various frameworks (although the differences between options on the same platform is definitely very useful information), but also the issue that few of us seem to think about these days: the cost of any of the frameworks above the bare standard library of the platform its hosted on. Theres a consistant, con…

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'm curious about that - because there's so little to webgo I suspect the answer is something really trivial. I haven't really looked at it before, but the framework itself is just 500 lines or so unless I'm looking at the wrong one...

Given that the json marshalling and server components would be exactly the same between go and webgo, I'm curious as to whether changing the url recognised to be just /json in the goweb tests would make any difference, any reason it was different?

Re: Web Framework Benchmarks

#108

Post by bhauer »

vph wrote: post #62

This seems to be a nice benchmark. For the Python group, I would suggest two things: (1) include a lightweight framework like Bottle, and (2) Try pypy.

Thanks. Agreed, we'd love to get a Python micro-framework in the test. If you have some free time and feel like putting together a test for Bottle as a Github pull request, we'd really appreciate that.

Re: Web Framework Benchmarks

#109

Post by bhauer »

pilgrim689 wrote: post #74
akg wrote: post #55

Would love to see how these results compare to some of the web frameworks for concurrent functional languages like Erlang/Haskell: Nitrogen, Chicago Boss, Snap, Yesod, etc.

ditto. I hear Warp (the server behind Yesod) is a beast.

I'm not familiar with Warp. Would one of you guys be willing to help us put together a test for Yesod?
Post reply on HN