Develop Reference

ASP.NET web forms website performance

I acquired an ASP.NET web forms website built by some contract developers. The site was pretty bad at first and ran pretty slow, but has been tweaked and in an isolated environment runs okay.
The site sits on a single (beefy) web server and connects to an Oracle database. The site is within a very large organizations data center but is not load balanced. Lately the site has received about 3-4x the traffic it typically sees and the site is crawling with about 4k unique users a day. IIS6 by the way. The IT dept. has examined the CPU and memory levels and they appear fine. I know there are some other tweaks I can make to IIS to cache static files and I am adding OutputCache to controls where it makes sense. However, what else could be the cause of a slowdown that appears to be caused by load? I'm unsure if the application pool needs more memory allocated or if the site is simply a piece of junk. I know the latter is true, but it surprises me that significant load would be a code-only issue.
Any ideas?

Look to see if indexes are applied to the queries/store procedures being run. Also, see if the page is doing selects or update/deletes. When you apply indexes it can slow down the deletes/update and spreeds up the selects.
Usually there are profilers in the database that can be ran on the queries and they will indicate what indexes should be applied to what table. See you Database admin to see if that can be ran on the store procedures you use.

ASP.NET application - ideas on how to speed it up

This is a very general question, so I won't be providing any code as my project is fairly large.
I have an ASP.NET project, which I've been maintaining and adding to you for a year now. There's about 30 pages in total, each mostly having a couple of gridview's and SqlDataSource's, and usually not more than 10-15 methods in the codebehind. There is also a fairly hefty LINQ-to-SQL dbml file - with around 40-50 tables.
The application takes about 30-40 seconds to compile, which I suppose isn't too bad - but the main issue is that when deployed, it's slow at loading pages compared to other applications on the same server and app pool - it can take around 10 seconds to load a simple page. I'm very confident the issue isn't isolated to any specific page - it seems more of a global application issue.
I'm just wondering if there are any settings in the web.config etc I can use to help speed things up? Or just general tips on common 'mistakes' or issues developers encounter than can cause this. My application is close to completion, and the speed issues are really tainting the customer's view of it.

As the first step find out source of the problem, either application or database side.
Application side:
Start by enabling trace for slow pages and see size of ViewState, sometimes large ViewState cause slow page load.
Database side:
Use Sql Profiler to see what exactly requires a lot of time to get done
Useful links:
How to: Enable Tracing for an ASP.NET Application
Improve ASP.NET Performance By Disabling ViewState And Setting Session As ReadOnly
How to Identify Slow Running Queries with SQL Profiler

Most common oversight probably: don't forget to turn off debugging in your web.config before deploying.
<compilation debug="false" targetFramework="4.0">
A few others:
Don't enable session state or viewstate where you don't use it
Use output caching where possible, consider a caching layer in general i.e. for database queries (memcached, redis, etc.)
Minify and combine CSS
Minify javascript

What to do now:
Look at page load in Firebug or Chrome developer tools. Check to make sure you're not sending a huge payload over the wire.
Turn on trace output to see how the server is spending its time.
Check network throughput to your server.
How to avoid this in the future:
Remember that speed is a feature. If your app is slow as a dog, customers can't help but think it sucks. This means you want to run your app on "production" hardware as soon as you can and deploy regularly so that you catch performance problems as they're introduced. It's no fun to have an almost-done app that takes 10 seconds to deliver a page. Hopefully, you get lucky and can fix most of this with config. If you're unlucky, you might have some serious refactoring to do.
For example, if you've used ViewState pretending it was magic and free, you may have to rework some of that dependency.
Keep perf on a short leash. Your app will be snappy, and people will
think you are awesome.

How can I be more productive building MVC C# applications?

I'm a relatively new C# developer, and I'm finding myself roughly 1/5th as productive building C# MVC applications in VS 2010 than I was doing it previous in Zend using php by hand using vim.
I work in an iterative cycle of write tests / write code / run tests / integrate & debug problems.
This last step involves building the code using visual studio, debug > attach to process > w3wp.exe and then visiting http://localhost/App/ (localy copy of IIS 7.5) and trigging some event/etc that kicks the VS debugger into running.
Upon finding a bug / issue I then stop the debugger, fix it, recompile and repeat.
This is unbelievably slow.
Compiling the application takes maybe 2 seconds, but the first time loading up in the debugger takes about 60-80 seconds. Turning the debugger off improves the speed of this fractionally, but not significantly.
There is nothing special about my copy of IIS; it's just configured to run locally serving the project directory from the visual studio project.
My machine isn't fantastic, its a 3.0Ghz duel core running windows 7 with 4 GB of ram... but this is just beyond a joke. I'm spending more time staring at my screen waiting IIS to do something than I am writing code.
Subsequent page loads are obviously really quick, you know instant page loads.
The issue, I guess, is that IIS needs to run application startup and load files and do whatever it does with the application pool worker when I recompile, which means the initial startup is slow (IOC, web config files, etc).
...and yet, I can't seem to find many other people on the net complaining about this, so I guess it must be some combination of how the application is configured, how IIS is configured and my workflow which are messed up.
What am I doing wrong?
If there's no way around IIS startup, how should I be doing development to avoid this problem?

I think most people use the Built In Visual Studio Development Server (IIS-like). If you are running SP1 you can also use IIS Express which is more robust for larger and/or multi/cross website applications.
Right Click on your Web Application -> Properties -> Web Tab to select a Debug Server.

I agree with you, that it might have to do something with your local system. Obviously it's not possible for me to tell you how your system is missconfigured, but I would check that first in more detail.
Some other hints which might be helpful, even if they don't solve the root of the problem:
Use the build in development server as Erik proposes.
If you have only changed templates, you don't have to restart from scratch.
If you have good unit tests, you don't need to start the web application at all.
Does IIS 7.5 have app pools? If yes, you could restart just the app pool, which is much faster than restarting the whole IIS.
PS.: I have seen quite some strange behaviours when opening database connections, if the network is configured in a bad way. Even if it's on the local machine, you might have strange DNS lookups or something like that. Just as an additional hint about what to look for.

Silverlight/WCF application is suddenly transferring extremely slowly

I have a Silverlight 4 application that works a lot with a WCF service. The application has normally ran fine, with fast response times for even some hefty queries. Recently however, it's gotten quite slow, and I'm having a hard time troubleshooting why.
My database is hosted on a remote server. The application is hosted on the same server. Here's what I've noted:
When I run the application locally, using the ASP.NET as my server instead of IIS, and I hit the website via localhost, which hits the remote database, speeds are fast.
When I run the application locally, but use the remote WCF service rather than the local service, things are slow.
When I run the application over the web, (i.e. the remote application which is, again, on the same server as the database, so they're local to one another) the application is slow. This is pretty much what the production environment is...
When I log on to the server, and hit the the website from within the server, things are fast.
The queries to the database are fast. Manually running the queries on the database themselves, yields the results in a split second.
Using the WCFTestClient and hitting the remote WCF service is also really fast, and has virtually immediate turn around.
Lastly, when I'm using the expected setup of my local machine hitting the website over the web, which hits the database, etc:
Not all queries react the same way. Some of the heavier queries which result in large data sets actually have a quick response time. Some of the light queries - straight SELECT statements with no JOINS, that generate only a kilobyte of data, takes a lot longer...about 30 seconds. There are a few queries that are sometimes fast, sometimes slow, but the ones that are always slow are the worst.
About the server:
The server is a dedicated server, I've monitored the CPU and it's not being taxed by anything. I'm hosting with IIS 7, on Win Server 2K8, and Sql Server 2K8. The only thing that's changed in the past few weeks have been some Windows updates, and I've been told by one person that they made some Firewall changes - that's my current theory on the cause, but I don't know what else to try at this point, or how to show that it is the firewall..
Any thoughts?

It's hard to find out the reasons according to what you described, I think you should start to profile your application by logging the database time, WCF request processing time etc.
Once you get the data, you can find the real reason. This is what we have been doing on our products.

If I had to guess, you're experiencing a combination of network latency and a less-than-optimal database design. Your description of "small" queries taking longer than queries yielding large result sets is a classic indicator that you need to evaluate your query plans, and ensure that they are using the right indexes (you are using indexes, right?).
I suspect that sorting out your database issues will solve a great deal of the slowness you're experiencing; caching query results in memcached or something like it will solve most of the rest.
Generally, WCF is the last place I look for performance problems - every time I've gone that direction in the past, the trouble ended up being our code; WCF performs admirable well for its size.
I'm sorry that I can't be more specific, but performance questions are quite application-specific and we don't have much information here to go on.

Fiddler. Fiddler was the answer (as it usually turns out to be.)
If you've experienced similar issues, hopefully what I've learned can be of help.
Here's what I saw:
First, when using both the Chrome/IE Profiler, it became clear that the Request itself was causing the lag, while the Response was quite quick.
This lead me down two paths of possibilities: Either the server was causing lag in the requests due to some specific configuration that I wouldn't see when running via localhost, or there was something wrong with the request itself.
After using Fiddler to get a full view of the request, it became apparent that it was the request I was sending. One of the objects I was passing as a parameter to my WCF service had a property that, when serialized, amounted to about 1 megabyte's worth of data - and that was with gzip enabled. Initially this object was a rather small object, but as the application grew, so did this particular object, resulting in the sudden slow down.
The reason why it happened for certain calls and not others was purely determined by whichever call had this object as a parameter.
The reason why it happens when going over the web, vs. going through the localhost is that over the web, you inevitably face your provider's Upload limit, as well as a number of hops until you hit your server, vs. the direct connection from your localhost to your database.
The lesson: Always transmit the least amount of information you can get away with.

ASP.NET MVC Debugging Very Slow - SQL Server Express Connection Issue?

I am developing an application in ASP.NET MVC, using SQL Server Express as the backend and Cassini as the development web server (the one that comes with Visual Studio 2008).
The application performance is blazingly fast (nearly instantaneous page switches). However, spinning up the debugger is painfully slow; it takes about 30 seconds from the time I hit F5 to the time the ASP.NET welcome page comes up.
I have noticed a similar delay when loading SQL Server Management Studio Express, and another delay when I open a table in my database for the first time for viewing. After I open my first table, everything goes smoothly.
Given the behavior of SQL Server Management Studio Express, I suspect that the problem lies in making the initial connection to SQL Server Express. Is this really where the problem is, and if so, how can I fix it?

I'd check the auto_close property on the database.
sp_dboption 'MyDatabaseName', 'autoclose'
I think the default on express might be to set autoclose to on. When that is set to TRUE, the server will close the database and free all resources from it when there are no users in the database. Setting autoclose to FALSE will tell the server to hang on to the database so that it's in the ready state regardless of users being in the database or not.
See here for more info.

If it's only slow when debugging, then there are several chokepoints to consider:
Applications start off slower when debugging because of the precompilation the JITer has to do whenever the assemblies are rebuilt.
If you're compiling and debugging every time, it may be your compilation that's slow, not so much your application performance. How long does it take for the browser to appear once you hit F5? If you have multiple projects in your solution, building them will take time. Try setting up a build configuration that excludes class projects (make sure to rebuild them manually when necessary)
I haven't had any trouble with Cassini, but you might try IIS just for grins.
Just a few thoughts, HTH.

I finally solved the problem by rebuilding my TCP/IP stack, using Netshell from a Command Prompt window. Apparently I was getting a TCP/IP timeout.
netsh int ip reset c:resetlog.txt
http://support.microsoft.com/kb/299357

In my case I was getting exceptions being thrown and caught which were visible in the Debug > Output window which was massively slowing down my app as it was being debugged.
I ended up enabling the break on exceptions as outlined here and then just fixing the code so not so many exceptions were being thrown
Why is ASP.NET throwing so many exceptions?