Improve - Efficiency and Scalability of ASP.NET Apps.

In today's scenario developing applications is not a big deal, but increasing the performance-efficiency and scalability is the big challenge faced by the developers.

Consider the following sections present these tips for ensuring application efficiency and scalability.

§          Move processing into Components

§          Avoid large pages

§          Remove dead code.

§          Avoid extra tips to the server.

Move processing into Components

You can increase application efficiency by moving processing into components and running those components as COM+ applications in Microsoft Transaction Server (MTS).

The efficiency gain occurs because—unlike your Web Forms—MTS doesn't have to instantiate a new component for each request; it instantiates components on demand but then keeps them in memory, ready for use, for a defined period of time. With that said, you can find a greater speed increase by caching .NET classes in memory at Application scope than in building MTS components.

Bear in mind that there's a performance penalty for running the components in a separate process, particularly the first time your application instantiates a component. For example, when your application uses a component only rarely, it may not be worth moving that component into MTS, because the performance and startup penalty may be greater than the delay associated with using the component to begin with.

Also, remember that an instantiated component uses server resources. If you only need the component periodically, you may not want to waste server resources on it during the bulk of the application time, when the application isn't using the component anyway. You can set a timeout value for MTS applications. MTS destroys component instances when they haven't been used for a specified amount of time. In contrast, for components that your application uses often, the penalty for initially instantiating an object becomes trivial in comparison to the time savings you realize by keeping copies of the object instantiated and ready for use.

Avoid large Pages

Try to avoid creating large pages unless you can cache the entire page. Instead, break the page logic up into smaller chunks—particularly if you can reuse those chunks in other pages in your application.

Try to design pages that require user interaction so that they fit on a single screen without scrolling. Although most users have become inured to long pages for reading information, it's extremely irritating to fill out a form only to find that the Submit button—and perhaps a few "hidden" fields—can be found only by scrolling around the page.

Remove Dead Code

As applications grow, you'll often find that older, unused code remains in the application. Even though your application may never use the code, the server must still compile it. Find and remove unused methods, variable declarations, components, Web Forms, Web Services, and client-side code blocks.

Avoid extra trips to server

As a final note, the greatest performance bottleneck in a Web application is usually the Web itself. This isn't as great a problem for intranet applications as it is for Internet applications; nonetheless, performing an action on the local machine is almost always faster than making a call to the server. Therefore, try to plan your applications so that you perform as much processing as possible locally, between server round trips.

One way you can do that is by downloading the interface to the local machine in advance and then retrieving just the data from the server itself. Of course, that's what Web applications were all about; by using a browser to draw the UI, you could maintain the entire application centrally, with no deployment or installation required. But another model is equally powerful and even better suited for many types of applications—the Windows UI running in conjunction with Web Services.

Like browser applications, .NET Windows applications can download a very small amount of user-interface code at runtime; in other words, you can deploy your application dynamically, on demand, via HTTP to remote clients. You can even deploy the .NET framework on demand, although that requires broadband clients because the framework itself is (in the first release) approximately 15 megabytes in size. However, with many if not most corporate applications, businesses can ensure that the client machines have the .NET framework installed in advance. With the framework in place, downloading the Windows Forms and logic required for an application's user interface is usually a very small download—in the thousands of bytes rather than the megabyte range.

That combination means that it's now both possible and efficient to deliver Web applications with Windows Forms front-ends that use Web Services to supply the data. By doing this, you gain more control over the application's interface, and the application looks, feels, and acts like the familiar applications people use on a daily basis. After all, there's little point in transmitting UI content over and over again via the browser if the user can run a similar but more powerful interface in native code.

Finally, as you've seen, planning your application around Web Services means you can get the customized UI available with Windows .NET-capable clients, take nearly instant advantage of your existing COM components, and still deliver the same application to browser-based clients or clients running customized user interfaces on other platforms. My advice is this: If you have any inkling that you may ever need or want to deliver an application to non-browser clients, plan the dynamic portions of your applications as Web Services whenever practicable, starting immediately.

    Happy Learning !!!.