Results 1 to 3 of 3

Thread: Tips for Writing High-Performance Web Applications using asp.net

  1. #1
    Join Date
    Dec 2009
    Posts
    32

    Tips for Writing High-Performance Web Applications using asp.net

    I am new to asp.net development environment, I have heard that writing web application in asp.net is very easy but you must know the tips related to it. Actually I need the tips related to asp.net web application for writing high performance web application. So can anybody help me with the tips and tricks related to web applications? I will be waiting for any related reply.

  2. #2
    Join Date
    Apr 2008
    Posts
    438

    Re: Tips for Writing High-Performance Web Applications using asp.net

    1. Return Multiple Resultsets
    2. Paged Data Access
    3. Connection Pooling
    4. ASP.NET Cache API
    Return Multiple Resultsets
    Check the code which is used to connect the database, that the request paths that is connected database more than once. The increase in these round trips reduces the number of requests per second to your server. If you use multiple resultsets for returning data in a single database request, then it reduces the total time used to communicate to database. This will make your system more scalable. This will definitely reduce the traffic on database and resulting increase the efficiency.

    Paged Data Access
    If you design the web page which gives the access to the data to the end user, then you must use ASP.NET DataGrid. The ASP.NET DataGrid exposes a fantastic capability of data paging. If you enable the DataGrid a fixed number of records can be seen at a time. For navigating through records ASP.NET DataGrid is provided with paging user interface at the bottom. Through paging user interface user can navigate in backward and forward. It can also be used to see fixed number of records at a time

  3. #3
    Join Date
    Apr 2008
    Posts
    438

    Re: Tips for Writing High-Performance Web Applications using asp.net

    Connection Pooling
    Setting up the TCP connection between your Web application and SQL Server™ can be an expensive operation. Developers at Microsoft have been able to take advantage of connection pooling for some time now, allowing them to reuse connections to the database. Rather than setting up a new TCP connection on each request, a new connection is set up only when one is not available in the connection pool. When the connection is closed, it is returned to the pool where it remains connected to the database, as opposed to completely tearing down that TCP connection.
    Of course you need to watch out for leaking connections. Always close your connections when you're finished with them. I repeat: no matter what anyone says about garbage collection within the Microsoft® .NET Framework, always call Close or Dispose explicitly on your connection when you are finished with it. Do not trust the common language runtime (CLR) to clean up and close your connection for you at a predetermined time. The CLR will eventually destroy the class and force the connection closed, but you have no guarantee when the garbage collection on the object will actually happen.
    To use connection pooling optimally, there are a couple of rules to live by. First, open the connection, do the work, and then close the connection. It's okay to open and close the connection multiple times on each request if you have to (optimally you apply Tip 1) rather than keeping the connection open and passing it around through different methods. Second, use the same connection string (and the same thread identity if you're using integrated authentication). If you don't use the same connection string, for example customizing the connection string based on the logged-in user, you won't get the same optimization value provided by connection pooling. And if you use integrated authentication while impersonating a large set of users, your pooling will also be much less effective. The .NET CLR data performance counters can be very useful when attempting to track down any performance issues that are related to connection pooling.
    Whenever your application is connecting to a resource, such as a database, running in another process, you should optimize by focusing on the time spent connecting to the resource, the time spent sending or retrieving data, and the number of round-trips. Optimizing any kind of process hop in your application is the first place to start to achieve better performance.
    The application tier contains the logic that connects to your data layer and transforms data into meaningful class instances and business processes. For example, in Community Server, this is where you populate a Forums or Threads collection, and apply business rules such as permissions; most importantly it is where the Caching logic is performed.


    ASP.NET Cache API
    One of the very first things you should do before writing a line of application code is architect the application tier to maximize and exploit the ASP.NET Cache feature.
    If your components are running within an ASP.NET application, you simply need to include a reference to System.Web.dll in your application project. When you need access to the Cache, use the HttpRuntime.Cache property (the same object is also accessible through Page.Cache and HttpContext.Cache).
    There are several rules for caching data. First, if data can be used more than once it's a good candidate for caching. Second, if data is general rather than specific to a given request or user, it's a great candidate for the cache. If the data is user- or request-specific, but is long lived, it can still be cached, but may not be used as frequently. Third, an often overlooked rule is that sometimes you can cache too much. Generally on an x86 machine, you want to run a process with no higher than 800MB of private bytes in order to reduce the chance of an out-of-memory error. Therefore, caching should be bounded. In other words, you may be able to reuse a result of a computation, but if that computation takes 10 parameters, you might attempt to cache on 10 permutations, which will likely get you into trouble. One of the most common support calls for ASP.NET is out-of-memory errors caused by overcaching, especially of large datasets.Common Performance Myths
    One of the most common myths is that C# code is faster than Visual Basic code. There is a grain of truth in this, as it is possible to take several performance-hindering actions in Visual Basic that are not possible to accomplish in C#, such as not explicitly declaring types. But if good programming practices are followed, there is no reason why Visual Basic and C# code cannot execute with nearly identical performance. To put it more succinctly, similar code produces similar results.
    Another myth is that codebehind is faster than inline, which is absolutely false. It doesn't matter where your code for your ASP.NET application lives, whether in a codebehind file or inline with the ASP.NET page. Sometimes I prefer to use inline code as changes don't incur the same update costs as codebehind. For example, with codebehind you have to update the entire codebehind DLL, which can be a scary proposition.
    Myth number three is that components are faster than pages. This was true in Classic ASP when compiled COM servers were much faster than VBScript. With ASP.NET, however, both pages and components are classes. Whether your code is inline in a page, within a codebehind, or in a separate component makes little performance difference. Organizationally, it is better to group functionality logically this way, but again it makes no difference with regard to performance.
    The final myth I want to dispel is that every functionality that you want to occur between two apps should be implemented as a Web service. Web services should be used to connect disparate systems or to provide remote access to system functionality or behaviors. They should not be used internally to connect two similar systems. While easy to use, there are much better alternatives. The worst thing you can do is use Web services for communicating between ASP and ASP.NET applications running on the same server, which I've witnessed all too frequently.

Similar Threads

  1. Needs some tips on article writing
    By Debraj in forum Technology & Internet
    Replies: 5
    Last Post: 13-11-2011, 04:41 PM
  2. Tips for making Video Games and Applications
    By Acardi !! in forum Windows Software
    Replies: 4
    Last Post: 21-09-2011, 11:46 AM
  3. Tips for Preloaded Symbian Applications/System
    By Baijayanthi in forum Tips & Tweaks
    Replies: 5
    Last Post: 25-07-2011, 05:59 AM
  4. Replies: 4
    Last Post: 27-10-2010, 02:48 PM
  5. High performance for ppc ads
    By Jaishree in forum Off Topic Chat
    Replies: 3
    Last Post: 11-07-2009, 10:31 AM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Page generated in 1,711,691,725.22179 seconds with 16 queries