MVC2 Performance on Windows Server 2008 R2 IIS7

964 Views Asked by At

I am deploying a MVC2 application under IIS7 on a Windows Server 2008 R2 server with plenty of horsepower. It's connecting to a SQL Server 2008 DB and the applications performance is dramatically slower than when running in the debugger on a developer workstation (connecting to the same SQL Server DB). I've already checked network connections and nothing in the eventlogs indicate an issue with Windows. I've also run the Profiler on the DB server and the queries are firing off fast.

Any help with diagnosing this performance issue would be appreciated. I've even built a new 2008 R2 server to test it on in hopes that it was the server itself but the performance was the same.

Thanks

Edit 1:

IIS is running on a Dell R710 server running Windows Server 2008 R2 Standard, 32GB ram. SQL Server 2008 is hosted on a separate R710 running Server 2008 R2 Standard, 12GB ram. Initially I had IIS running on a VM but I moved it to the physical machine to see if performance degradation was due to the VM. I'm experiencing the same performance on both so it looks like it wasn't a factor.

Edit 2:

It appears that opening the connection to the database is part of the bottleneck with the subsequent firing of stored procedures also taking a considerable amount of time:

-Open db connection: 5 sec (subsequent connections are cached so they don’t require 5 seconds)

-First sproc : < 1 sec

-Second sproc: 5 sec

-Third sproc: < 1 sec

-Fourth sproc: < 1 sec

-Fifth sproc: 6 sec

2

There are 2 best solutions below

1
On

Here are slides from a presentation about optimizing ASP.NET MVC applications. They were able to improve their app's performance from 8 req/sec to 400 req/sec.

They mention in the slides how they profiled it and identified bottlenecks (query compilation, many calls to RenderPartial, url generation etc.) and give some tips at the end of the presentation.

5
On

First, Windows Server 2008 R2 has IIS 7.5, not IIS7. Probably doesn't matter. However, it is a different version.

Second, you need to find out where the bottleneck is. Try removing the queries and just using dummy data. Is it still slow? If not, then it has nothing to do with the data access.. if so, then you know it's a data access issue.