Hacker News new | past | comments | ask | show | jobs | submit login

Techempower's benchmark's paint a different story than you describe. Node.js seems to be the fastest. ASP.NET MVC shows some strong performance in a handful of database tests but when it comes things like json serialization etc it falls behind the competition.

http://www.techempower.com/benchmarks/#section=data-r5&f=ug-...

Edit: FWIW it doesn't test Microsoft SQL Server. Still, for most simple-ish web applications I can't imagine MSSQL server being significantly faster than Postgres or MySQL. Its selling point is really its feature set as opposed to its performance anyway.




>Edit: FWIW it doesn't test Microsoft SQL Server. Still, for most simple-ish web applications I can't imagine MSSQL server being significantly faster than Postgres or MySQL. Its selling point is really its feature set as opposed to its performance anyway.

More than just that, they tested mono, which sadly is often very slow, and didn't test on IIS.


The ASP.NET tests run on Windows (EC2) used IIS. We have a SQL Server pull request [1] but haven't been able to incorporate it yet and this will not be included in the upcoming Round 6.

https://github.com/TechEmpower/FrameworkBenchmarks/pull/336


Had a little look at this whilst waiting for a shower, so I was on my phone, apologies if I missed anything.

My understanding is Node.js is caching the same read requests to avoid having to hit the DB?

ApiController does not do that by default in MVC4, for reasons best known to themselves, regular vanilla controllers do.

However, this: https://github.com/filipw/AspNetWebApi-OutputCache

Fixes that.

I appreciate it might be cheating a bit to bring in a 3rd party library when looking at a full stack provider, but it would explain the discrepancy between Read and Write performances.

Additionally, with the EntityFramework (MS's ORM) when the security you are using is not that of the SQL back end, it can be beneficial to 'cache' it, rather than use a session each time. There are obvious cons to this, but it is a very real world scenario, one of the nice things about an ERM (Entity-Relationship-Model), well the only nice thing, is that it ensures the integrity of the data. Assuming you defined it correctly, which is sometimes an arse, in the same way you don't end up with the perfect 3NF design the academics taught us.

I've put a reminder in my calendar once I'm done on this project (all hands on deck time, as the business has imposed a deadline, without consulting...) I feel I could give a more realistic example.


The problem is the comparisons are a bit tricky.

For instance why is the performance in the Fortune example so good, yet so bad in the simple multirequest response.

Ultimately, I think people have to bench with something in mind for their intended usages.

If someone (as in this thread) is doing some massive data gathering with 6000+ nodes, well windows licenses will be prohibitive against any dev time saving, and ultimately, performance is going to be optimised so heavily a 'thinner' OS is obviously going to be a possible better choice.

This isn't always the case, for us the agile nature of what we are doing, the fact it's only a couple of hundread nodes means that we will have different demands.

Platform Performance, Platform Cost, Platform Dev Costs.

It is just an exercise between those three. Looking at some of the comparisons there, it reminds me of the whole BSD vs Linux thing that was so 2004. Oh BSD takes a few extra op codes to do hello world....

The problem is some people never include the use of say MVC4 or C#. It isn't that they are missing out, it is that they are so vocal about how bad the platform they have never used is.

The last HTML site I delivered, I could have done in about a third of the time, with much more reliable user experience if we had used Silverlight. It was an internal project too. Yet someone who had never even used anything but HTML decided it had to be a website.

I think people are just trying to rally against that cry. All I was trying to do is point out that those simple number comparisons are not only flawed / unfair but also irrelevant.

There isn't a one size fits all technology, there never will be.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: