Performance reprogramming website in MVC3 with Entity Framework

At the moment I have开发者_Go百科 a fairly big website with about 10k visitors a day.

This is a community website with news/blogs/videos and a big forum.

This all runs on a self made PHP5 application which performance faily well, has good performance. The database is a MySQL5.1 database.

Now I am getting fedup with PHP and the loose typed framework, lack of namespacing and a proper MVC setup, so I am thinking of rewriting the site in MVC3 ASP.NET.

Now I have experience with this, but not in the MVC framework yet, and I have a few questions about the performance, especially the Entity Framework: Is it even worth using the entity framework? Will it cost alot of overhead and performance degration? I am not sure yet if I should switch to MSSQL.

Entity Framework was not performance optimized as far as i have worked with it. That is not it's primary goal by design. Performance is important of course, but EF is at most easy to use, and start with. It provides an fast way integrate with existing database, or create database really, really fast. Performance is not the primary goal, but improving indeed.

Here is an good chart with some benchmarks from the Microsoft team, that can be a ground for making the decision. As you can see, there is a dramatic performance improvement from .NET 4.0 to 4.5 as far as it comes to "LINQ to Entities". It still seems twice slower than direct SQL though. LINQ to SQL is the slowest operation of course.

ASP.NET MVC is an good direction, especially if you want to try something different. EF is not the best you can do if you pursue performance. Writing the business layer on your own, including the SQL stored procedures would be better, but will require a lot more time.

When using an ORM like EF or NHibernate you always have to live with the trade-off between performance and convenience. If you can live with a relatively bad performance (I think it should be possible to run your site w/ an ORM) NHibernate should your first choice, from my point of view it is more mature while EF is still lacking provider support and has some shortcomings with respect to the develevopment workflow (which you possibly expect when using NHibernate but not when using a MS tool).

If you switch from PHP to .NET you should consider switching from MySQL to MSSQL, just because it fits perfectly into the MS ecosystem (and performance/scalability should be improved too, this could possibly outweight the performance degradation you expierence when using an ERM).

You could also take a look at LINQ which could be an alternative between a classic ORM and hard coded SQL commands (also with respect to the performance, LINQ to SQL is pretty fast and you can also use LINQ to Entitiy Framework when using EF (thats pretty slow)). LINQ would fit your needs if you want some level of abstraction wihtout the need of endless configuration and if you like RAD (who doesn't?).

In general the performance of ASP.NET MVC3 is quite good, but you should know that you need some experience to tweak your application and avoid (common) pitfalls. Cutting a long story short: You should be easily able to write an ASP.NET application that has a better performance than a scripted PHP page (by design)

But you should also know, if you decide to commit yourself to the MS ecosystem (.NET, MSSQL w/ LINQ/EF) its hard to break out and providers for LINQ and EF for non-MS RDBMS might cost some bucks (check www.devart.com).

Hope this gives you some guidance

Further reading:

• ORM wars: Comparing nHibernate, LINQ To SQL & the Entity Framework
• NHibernate vs Entity Framework: a performance test
• NHibernate vs. Entity Framework 4.0

This is way too much of a general question, and there's no good answer to it. I highly recommend that you perform some tests using the Entity Framework as well as MVC3 and see that it meets your needs.

Also, and not to be condescending, but 10K visitors a day is not that much compared to other sites out there that are succesfully running ASP.NET MVC and Entity Framework.

In the end, I'd say it most definitely will meet your needs, but as with any project that scales, you will have to be aware of bottlenecks in your particular app and come up with solutions to address those bottlenecks.

This is 100% dependent on the queries.

I've worked on sites with 22 million a month with Nhibernate and about 10 million a month with Linq to Sql.

The queries that performed the slowest were always those weird aggregate quintuple join monsters. ORMs get you 95% of the way there. The rest you'll have to optimize. No ORM gets SELECT * FROM table wrong. Its the outliers that matter.

This will probably get closed as subjective/argumentative in the next five minutes, but I'll give it a shot:

You'll hear a lot of differing views regarding EF and other ORMs, but my personal view is that they cause more problems than they solve. Queries should be kept in the database, where they belong. Proper separation of concerns (SQL code in the database, app code in the project) saves you a lot of problems long-term.

Think of it this way: if your queries were all in stored procedures, you wouldn't even be thinking about migrating/rewriting them at this stage. You could focus on implementing the web side of your app instead of worrying about how to transition your SQL code.

So, skip EF for now, focus on what you know.