Where is ASP.Net MVC? Odd that you list obscure frameworks like Wicket and leave out one of The Big Four frameworks. (The big four in my book are: ASP.Net MVC, Rails, Django and CakePHP)
Drop me a line if you need a hand with either :)
301–310 of 415 posts
Where is ASP.Net MVC? Odd that you list obscure frameworks like Wicket and leave out one of The Big Four frameworks. (The big four in my book are: ASP.Net MVC, Rails, Django and CakePHP)
Drop me a line if you need a hand with either :)
And also maintains .NET's fastest JSON and Text Serializers: http://theburningmonk.com/2011/11/performance-test-json-seri...
I Will love to see dotNet (C#) incluid in this test. Asp.Net WebAPI (Synchronous and Asycnhrounous) Asp.Net MVC (Synchronous and Asycnhrounous) Asp.Net HTTP Handlers (Synchronous and Asycnhrounous)
ServiceStack 9615ms
WebApi 30607ms
GitHub project for benchmarks used: https://github.com/anilmujagic/ServiceBenchmarkEarlier quoted context omitted.
What's wrong with that guy?
He's a fantastic software engineer but he is _very_ abrasive. I've read some of his posts claiming he would fight some other developer in person at a conference if he steps up. He would rent out a ring and he would put his yellow belt to practice. Really, I'm not making this up. He sounds like a jerk to work with.
Zed Shaw is probably one the best people you can know in the developer community, a very good guy.
Your sensationalism based on some of the stuff he says on Twitter and Blogs is amusing though.
I worked with Pat (pfalls) on this effort. He pulled the benchmarks together and built the script to automate the tests. We aimed to deploy each framework/platform according to best-practices for a production environment and then stress test common operations: JSON serialization of objects and database connectivity. We were surprised by the wide spectrum of performance we observed and hope that this interesting to yo…
I'd be interested to see performance for Vert.x on its other hosts (this is the JVM version, I believe).
While vert.x supports many programming languages, all of these are run on the JVM runtime. This means when you use the ruby vert.x API, you're using JRuby; likewise with Javascript run through Rhino, Python through Jython, and Groovy/Scala run through their own interpreter/compilers.
That said, it would definitely be interesting to see the performance implications of using one of those languages and vert.x on the JVM.
How the hell can you compare accessing a MySQL database to accessing a MongoDB database?
Its like comparing apples to piles of poop.
Also when you're testing things like Django in web requests, you're testing gunicorn, not Django.
Would love to see how modern Perl frameworks (Mojolicious/Dancer) ranks in such a test.
Earlier quoted context omitted.
We used Phusion Passenger, although we have plans to add additional servers (such as Unicorn). We tried to spend time with various server choices for all platforms, and for ruby, in our short test, Passenger won out against the others. Our understanding is that when running Passenger, simply passing '-e production' to the command line is sufficient to run in production, but if that's incorrect, we'll gladly update th…
Please make sure you're setting higher GC limits for the Ruby tests. Ruby's defaults are awful for a framework, and result in a LOT of GC thrash. It's not uncommon to see an order of magnitude improvement in performance when they're tuned properly. (edit: I'll just send a pull request, I found the setup file!) Something else you might consider is the OJ gem rather than just the stock Ruby json gem. The latter is noto…
Could you elaborate on this, or point me in the right direction? I'm learning Rails and curious.
Earlier quoted context omitted.
How is it broken?
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…
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)