ASP.Net Applications Performance Improvement - 2

In my last post, you saw a few tips to improve the performance of your application tuning at the client side.You saw that we can do a lot of things really in your code to get benifitted.

This post is all about the things you can do at server side code when developing an application to ensure good performance.

In General, the top Reasons for Performance Issues in Application are
  1. Resources Affinity
  2. Excessive Allocations
  3. Failure to share expensive resources
  4. Blocking Operations
  5. Misusing Threads
  6. Making late-bound calls
  7. Misusing COM interop
  8. Large Pages
  9. Failure to use caching appropriately
  10. Inefficient rendering

Few considerations to improve performance when designing an application.
  1. Consider security and performance
  2. Partition your application logically. (layers, tiers, files etc)
  3. Evaluate affinity
  4. Reduce Round Trips
  5. Avoid blocking on long-running tasks
  6. Use caching
  7. Avoid unnecessary exceptions.

How to reduce expensive round trips?
Use  Response.isClientConnected property
Whenever you do server processing, check this property just like you do a check for IsPostBack.
This tells if client is connected still. Don’t execute your code if client is not connected.
Say if power goes off, x button clicked, browser closed, you really don’t have to execute your code.
IsClientConnected Boolean property helps you to achieve that.

Caching (Not Client Side)
Use App Fabric Caching for webfarm kind of scenarios:  That is, Caching on Server. Don’t do DB calls simply. See if data is available in cache.
Say, with a load balancer, a website running on 4 Servers with a database can have App Fabric Caching instead of caching data on 4 machines also.
Supporting Platforms: If server is 2008, 2008 RT or Win 7.

How it works?
Normal Caching at server side : In first hit to db, caching the data will be done on all 4 local servers.  In network environment this is expensive.

So, Have 1 cache instead. Distributed In-Memory Cache. Have an App fabric cache cluster. It’s free, download it.  It works only with 4.0 .net.
Request first goes to server and then to a common cache instead of going to database. If data is not in cache, it routes to database. It is fast as cache is in memory & not on a disk!
See codeplex for more details on implementation.
You can do it programmatically or even without any programming. WCF and Winapps also supports aapp fabric caching.

Output Buffering
Use Response.flush. It sends response upto the point it has to the client. Also Use Response.buffer and Response.BufferOutput for a page to buffer it.
Even for whole page , buffering can be enabled. Set buffer="true" in page directive.
For whole app buffering, in web.config, set
<pages buffer="true">
Instead of Server having a chatty conversation with client, it will have a batchy conversation with client now. Isn't it great?

Disadvantage : It shows u blank in UI as things go to process on a batch and come back. Design pages smartly to avoid this. Load something and show it to user.

Don’t user Response.redirect for navigating within same domains. Use Server.Transfer whenever possible.
80% of response.redirects can be converted to server.transfers in any application mostly except for the 20% which are required due to security/authentications requirements.

In Code
When you open a db connection, don’t do anything else except doing a db operation. Don’t do calculations and all. It is expensive.

Allocation Pattern
Ex : Using String.Split to many times or += to concatenate sting many times or on every postback.
This makes .net framework to create many objects in background and gives much load to GC. Do not do these things in code.

Popular posts from this blog

Facebook Javascript API : Feed and Share Dialog for Beginners

Developing a Link Chopper using C# and API in 1 Hour

Real time Push Notifications with SignalR & PNotify (Pines Notify)