views:

659

answers:

13

Hi,

For enterprise web apps, every little bit counts.

What performance tips can you share to help programmers program more effeciently?

To start it off:

  1. Use StringBuilders over strings since strings are Mutable (they get re-created everytime you modify them).

  2. Avoid using Datasets as they are very bloated, using SqlReader instead.

A: 
  • Make good use of the Cache object for any data that doesn't change very often but gets used alot. If you need to keep your cache objects in line with your database, have a look at SqlCacheDependency.
  • Disable ViewState wherever it isn't required
flesh
yes, viewstate is a big one.
+3  A: 

We deal with this every day.

We DO cache some datasets that are used A LOT. We have a fairly complex data-layer caching mechanism that works well for us.

Lazy evaluation for just about everything.

Page- and partial-caching for user controls

We do not use session state at all so we've disabled it altogether.

Configure websites to run as a known- low-prived user.

Connect to SQL Server as the same low-prived user. This helps with connection pooling - all connections are essentially the same.

NO ad-hoc SQL. Stored procs ONLY. Helps with performand AND SQL injection.

string.Concat() instead of string + string + ... or StringBuilder

n8wrl
string.concat uses a stringbuilder behind the scenes I'm guessing?Never heard of the lower privledge 'trick'?
No, string.Concat doesn't use a StringBuilder. But string + string + string just calls string.Concat...
Jon Skeet
Keep in mind that Linq-to-SQL prevents SQL injection as well. And that there is little advantage to using stored procs over paramaterized queries, as they both use the same method for execution plan caching.
Sam Schutte
No real magic to 'low priv' user - just can't do much. All it can do is execute procs, for example, so if someone were to somehow hijack the site and try something nasty against SQL they couldn't do anything but call procedures - do dynamic DML, no DDL (table drops, etc.)
n8wrl
+1  A: 
  • access database as little as possible
  • access web.config as little as possible
  • as manwood says make good use of cache. I could also suggest to read this very good article about kernel mode caching
  • avoid locking if you can
  • some things (like sorting of data) can be done client side nowdays(see Jquery)
  • here is good article to read
+21  A: 

The points made in the question are micro-optimisations. I disagree with the very premise that "every little bit helps" - particularly if it comes at the expense of readability.

You see, if you can read and understand your code really easily, that means you can make architectural changes easily. Those are where the really big wins are, not the micro-optimisation. The more you try to tune the heck out of every line of code, the harder it will be refactor the whole design.

So my tips are:

  • Write the most readable code you can
  • Don't optimise the implementation prematurely - but think about architectural performance issues early
  • Don't make changes in the name of performance until you've got hard numbers to let you tell whether or not you're improving things
  • Use a profiler to help spot bottlenecks

None of this is specific to web-apps, so far. For web apps (and server-side in general):

  • Unless you really know you'll never need more than one server, make sure your code can scale horizontally. If you can afford to do so, start with two servers (or more) so you can iron out any issues (sessions etc) early. This also helps with rolling upgrades etc.

EDIT: I didn't address the database at all. Kyle's answer is good on that front. Make sure your database can scale too, if possible :)

Jon Skeet
+12  A: 

the biggest gains you're going to see in (almost) any application is tuning your database.

Coding ...

  • Are you selecting a dozen columns when you only need 2?
  • Are you grabbing all the results to perform a SUM?
  • Are you grabbing 1,000 records to display 10?
  • Are you firing off a hundred queries every page?

Database ...

  • Do you have indexes on your tables?
  • Are they the right indexes?
  • Have you grabbed some sample queries using SQL Profiler and checked out their execution plans in Query Analyser?
  • Are you seeing TABLE SCAN - BAD!
  • Are you seeing INDEX SEEK - GOOD!

And if all else fails, cache the shit out of it and throw more hardware at the problem! :)

Kyle West
Don't forget: Are you seeing CONVERT() on queries against large tables - VERY BAD!!!
Mike Burton
+1  A: 

Aside from the database another very imporant thing to watch ...

page size and number of requests. This should go without saying, but ASP.NET is notoriously bad at filling your pages with a bunch of crap output (driving up the size) and creating a million external script files (number of requests).

Kyle West
+3  A: 

Except for manwood nobody mentioned ViewState and it's quite surprising. I would vote ViewState Management as the single most important considerations for performance improvment.

My list:

  1. Manage View State aggressively
  2. UpdatePanel is evil ;) Make Juridicious use
  3. Leverage JavaScript frameworks such as jQuery
  4. Watch your server roundtrips
  5. Use Async pages for IO bound operations
  6. Caching at various level is equally important (Page level, data etc.)
  7. Using Ajax to fetch data "on demand" and cache locally as XML (XML data islands etc.)
  8. Consider async processing for long running operations (you can either use database based job queues and have them processed through a windows service. An ajax request could monitor the row for completion and update UI using balloons)

Edit: [added 6-8]

Vyas Bharghava
A: 

examine the log and minimize the amount of HTML being served per request. viewstate and bloated third party controls can ruin your application. For example we used for a long time the grid from infragistics. very very capable but even in its stripped form it made pages about 60-90k + a lot of java script. this severely limited the number of requests we could server, even on an internal gigabit connection.

MikeJ
+2  A: 

Microsoft has published a book called Improving .NET Application Performance and Scalability. This is a must read book.

Jonas Kongslund
This is from 2004. The .NET Framework has certainly changed a lot since then. Is the book still up to date and worth reading in your opinion? Just checking. Thanks.
CesarGon
A: 

In my experience, the following make a big difference:

  • Use SQL Server Profiler to identify slow running queries. In particular use the tuning template to see if you missed out on any indexes.
  • Cache sensibly (Caching Application block)
  • Keep an eye on ViewState
  • Use Fiddler to check page size etc.
JohnC
+1  A: 
  • Post back as rarely as possible. Use DHTML & JavaScript to manipulate the page when users are making a complex set of critera choices. Don't post back to make changes in a page in response to every little user setting.
  • Use ASP.NET controls are sparingly as possible. Use plain html as much as possible. All ASP.NET controls come at a cost because of view state and control state. Plain HTML does not have this overhead. I once did a web app for Citibank which consisted of one main query page. This page was moderately complex. It had only one ASP.NET control on it. It was a button that posted back to manufacture a custom Excel sheet, loaded with user selected data.
  • Use the MVC framework rather than ASP.NET. Viewstate and control state are out of the picture here, if you use Brail or NVelocity.
  • Run Ants profiler by Redgate software on your back-end code. Make sure your postback event is as short and sweet as possible.
  • If a page derives data from a table that is refreshed once every 24 hours or once per week, don't write a comon ASP.NET page to query the data each time a user makes a request. If the data is static, make the page static also. You can generate static pages on an NT Scheduler basis using XML literals & Linq to XML classes. This is the biggest speed up I can give you.
David Leon
A: 

If your web servers are being pounded by huge number of simultaneous requests, and each page requests appear to take longer and longer to service, you may want to consider converting to asynchronous page processing model.

Scalable Apps with Asynchronous Programming in ASP.NET

icelava
A: 

I made kind of checklist for myself first and later I thought it would be also beneficial for others. I gathered things together and it became kind of a big checklist and wanted to share them as entries. Here it is;

http://www.yasarmurat.com/Blog/28/tuning-optimizing-increasing-and-improving-performance-of-asp-net-application-part-i.aspx

Hope it can help someone.

Regards, Murat.

Murat Yasar