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

261–270 of 415 posts

Re: Web Framework Benchmarks

#261

Post by sp332 »

k__ wrote: post #171
vanderZwan wrote: post #160

"Among the many factors to consider when choosing a web development framework, raw performance is easy to objectively measure." Oh really? Then why did Zed write such an angry rant about how you are doing it wrong? http://zedshaw.com/essays/programmer_stats.html Can we please see some standard deviations, at least?

What's wrong with that guy?

He's a lifestyle ranter. He used to have a section of his website called /rants/ which you can still read here: http://web.archive.org/web/20080105054424/http://www.zedshaw...

Re: Web Framework Benchmarks

#262

Post by Joeri »

bsingh4 wrote: post #242
krg wrote: post #3

There is a huge difference between raw PHP and CakePHP. I'd be curious to see other PHP frameworks (such as Zend, or Slim) in there-- is Cake just particularly slow, or is that simply what happens when you have a PHP framework?

Also, it would be beneficial to see Phalcon PHP - its implemented as a C extension so should theoretically be faster. http://phalconphp.com .

If we're going that route, the fastest php performance you would probably get from facebook's HHVM JIT compiling php engine: https://github.com/facebook/hiphop-php

It's no accident that zend optimizer (bytecode cache) is being bundled into php 5.5 as open source, as mere bytecode caching is now not fast enough to charge money for when hhvm is open source. I expect the next version of zend's commercial php server product to contain a JIT engine to match what hhvm can do.

Re: Web Framework Benchmarks

#263

Post by bilbo0s »

goodwink wrote: post #223
bilbo0s wrote: post #128

Earlier quoted context omitted.

I'm not sure many people would use webgo in real life. I don't know... maybe some people... certainly not pros. Also, the 1.0.3 thing is probably dragging on the numbers a bit. 1.1 would boost it a little. Not enough to get it into the top tier... but a little. Also, for Vert.x, they seem to be only running one verticle. Which would never happen in real life. Play could be optimized a bit... but not much. What they h…

Could you point me at an example of an idiomatic, non-trivial Go REST/JSON API server? I've been trying for a while to find something to read to get a better handle on good patterns and idiomatic Go, but I haven't really come up with anything. I've found some very good examples of much lower-level type stuff, but I think I have a decent handle on that type of Go already. What I really would like is a good example of…

Sorry... I'm not really a book kind of guy when it comes to this stuff. The golang resources are mostly what I use.

Re: Web Framework Benchmarks

#264

Post by vinay_ys »

For json serialization, this benchmark seems to indicate Netty is twice as fast as Golang. Don't think that's right. The golang benchmark code is not exactly equivalent to netty benchmark code.

The netty code creates the ObjectMapper once and uses it for all requests, whereas golang code creates the json encoder for every request (enc := json.NewEncoder(w)). Just getting rid of that would make this trivial code so much faster.

Re: Web Framework Benchmarks

#267

Post by pekk »

papsosouid wrote: post #138
goodwink wrote: post #88

Earlier quoted context omitted.

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

Or it could speak poorly of their release process, which is more accurate. The stable release is simply so bad compared to tip that everyone uses tip. There should have been multiple releases since the last stable release so that people could get those improvements without having to run tip.

Why not both? Insisting on a very stable API can result in long times between releases, which can mean more people using tip. That's distinct from how stable tip is.

Re: Web Framework Benchmarks

#268

Post by pekk »

goodwink wrote: post #215
marcamillion wrote: post #185

Earlier quoted context omitted.

Not quite sure I understand your point re: the cost of the frameworks, above the bare standard library. Do you mind breaking it down for me a bit please? Cost in dollars or cost in hardware utilization or some other cost?

If you have developers who for one reason or another prefer a given platform, then the most important performance comparisons are about how close various frameworks on that platform get to the performance of the platform itself. Knowing how much I'm giving up in performance in order to get the features a given framework gives me is an important consideration. Also understanding when it's worthwhile to work outside th…

How do you derive how much performance you are giving up from these benchmarks? There is not a neat relationship between the two.

Re: Web Framework Benchmarks

#269

Post by papsosouid »

pekk wrote: post #267
papsosouid wrote: post #138

Earlier quoted context omitted.

Or it could speak poorly of their release process, which is more accurate. The stable release is simply so bad compared to tip that everyone uses tip. There should have been multiple releases since the last stable release so that people could get those improvements without having to run tip.

Why not both? Insisting on a very stable API can result in long times between releases, which can mean more people using tip. That's distinct from how stable tip is.

Given the frequent complaints that the previous stable release isn't very stable, I think trying to interpret it as "tip is super stable" is wishful thinking. Tip is currently less bad than stable. The fact that stable releases are not stable is a bad thing, not a good thing.

Re: Web Framework Benchmarks

#270

Post by kainsavage »

fatbat wrote: post #255

I see alot of people saying how certain configs are missing/better/not tested. So what about a "crowdsourced benchmark" instead? Maybe a few elaborate scenarios are posted and people can simply submit their best setup/config/code to be benchmarked. I imagine devs would improve on it over time and eventually the most optimized would surface?

We are doing precisely that: if there are any mistakes or misunderstandings about the production-level best practices, we are accepting pull requests on our github (set up with all these tests, in case you want to run them yourself) to fix them, rerun them, and then report our updated findings.
Post reply on HN