a ton of text

Building High Performance Web Applications in asp.net

Part I: Overview and Architecture

Overview

In the hands of a master coder and architect Asp.net can be a very powerful platform for building high performance web applications. All too often Asp.net is used more like a rapid development tool rather then a framework for building high performance web applications. As a result the general view of the IT community is that general performance of .net web applications is inferior to that of it's competitors. This is unfortunate because though it is true that some platforms do offer slightly better overall performance, most of the performance issues in .net web applications are due to bad development practices.

In this article I will review the common mistakes made by some .net developers as well as document .net performance tips, suggestions and best practices for developers and architects when developing web applications in .net.

The Problem

Before we review guidelines and best practices we need to first address the problem. I find that many .net web developers do not consider the performance of their web applications until the point of near completion. At this point in the process their is very little that can be done to properly address the overall performance problems without rewriting the entire application.

The first thing that you need to do in order to write a high performance web application is admit to yourself that you are a developer working on a web site. Visual Studio has many nice features that work effectively to disguise your web application as a winforms application. These features can be great when implementing rapid development on a content management system which will have at most 10 simultaneous users sitting all of 10 feet away of the production environment, but if you are building a client facing web application this is frankly just not going to cut it. As a developer working on a high performance web application you will need to understand the execution of a .net web page and the architecture of a web development application. You will also need to write html, write javascript and understand object oriented concepts. This article will touch on many of these concepts but I urge you to be aware that ultimately your project is a web application which states that ultimately you will need to employ the skills of a web developer in order to achieve the results you require.

Be A Leader

As the developer of a high performance web application you will be required to make decisions in terms of business rules, best practices, architecture and implementation. If you want to build a high performance web application it is important that you be the champion of your web application. It will not fall into place by itself and no one is going to do it for you. Regardless of your role in your organization if you wish to build a high performance web application you will need to lead by practice and example.

Requirements Gathering

Despite your life-cycle development framework good up front requirements gathering is always required at the start of any high performance web application. The information gathered at this stage of development will define you business objects and business logic. These two items define your web application architecture and based on that architecture you will determine best practices for performance. It is very important that you as a developer come to an understanding and agreement with all parties of how everything will work. All to often I hear the excuse from a developer that the his perfect system was destroyed by the decisions made by others while he was in development. As a developer it is your responsibility to organize and manage your own project. You are the experienced professional and they are depending on you to make good choices. A good doctor does not treat his patients based solely on what they think their ailment is, he will first conduct tests to verify the ailment and consider other ailments before starting treatment.

Some advice on requirements gathering:

• Meet strictly about business requirements: Often times organizations will try to kill many birds with one stone. You may find yourself being brought into a meeting which encapsulates marketing, design, goals and some business requirements. This is not enough information to begin working! Use this time to understand the basic concepts of your project and formulate the questions you need answered. Then schedule a second meeting with decision makers to define your business rules. Make sure you are prepared with the right questions for this meeting.
• Make sure you understand the project completely: Before you put pen to paper make sure you understand everything completely. Don't be afraid to ask a question. In most cases if there is an item you do not understand it usually points to something that has not been thought through completely. You cannot design an application for peak performance without understanding it.
• Trim the fat: Often times "the fat" is the cause of bad performance in web applications. Try to remove as many unnecessary business rules and features that you feel will effect performance. Make recommendations to the decision makers in your organization and provide alternate methods of achieving the same goals.
• Define Risks Publicly: Don't keep risks to yourself, define them publicly. Any design pattern you choose will have a shortfall. Defining risks publicly will give players on your team a chance to chime in and make a correction before you are near completion of development.
• Force people to review your specifications: After you have put together specifications make sure the decision makers in your organization read them and understand them. Often times they may tell you everything is good but they did not take the time to review your specifications completely.
• Be adaptive and predictive: Despite all of the techniques defined above changes will creep their way into your web application project for the entirety of its lifetime. Understanding this, design your application to both adapt to changes and still deliver high performance.

Architecture

The .net framework does assume some generic architecture guidelines for your project but be sure that when defining your architecture that you are choosing the right architecture for your specific project. Be sure to research the latest and greatest technologies available to you at the time of implementation and analyze the performance advantages of each. As a general rule when designing the architecture of your project try to design it with a five year shelf life. This may seem like a short time but in the world of web development five years is a very long time. Also be sure to make your architecture scalable and adaptive while still retaining excellent performance.

Class Structure

One of the most common mistakes I see developers make is when they are designing applications is that they by default think about the data model first and class structure secondly. This often times results in a class structure that is simply a dump of the data model, or which is not object oriented at all. Using this methodology sells the potential performance of your web application short.

For this reason I recommend that you first design your class structure then design your database model. When considering performance at the class level many more options are available to you. You can define many complex geometric shapes such as cubes and trees and much data can be stored in a way that cannot be done as efficiently when forced to store data in flat relational tables.

• Use Inheritance: Inheritance is a very basic concept that most developers have a good understand of but often times do not employ. In .net web application your web application will be compiled at runtime to the gac so unlike many interpreted web programming languages you will not get as much of a performance increase from using inheritance based on limiting the lines of code you write, but by defining relations between your objects using inheritance rather than creating new instances of objects to define relations the overall memory footprint of your web application will decrease as well as decreasing the amount of time it takes to construct an object.
• Think about how your data objects persist in memory: From your requirements gathering you should have a good idea of how your business data objects should persist in memory. Generally in web applications your data will fall into 3 categories.
  • Data that is the same for every user and is frequently accessed: For data of this kind you will get best performance if all users access the same instance of the same data. this will limit the number of transactions back and fourth from our data store. Implementing these techniques will be covered more in debt in Part II of this article.
  • Data that is the same for each user and is frequently accessed: For data of this kind you will get best performance if you employ state management techniques to hold this data. Thus limiting transactions going back and fourth between your database and at the same time protected this data in an instance that is only accessible to the user. State management techniques will be covered more in debt in Part II of this article.
  • Real time data and data which is not frequently used: For this type of data it is best to just recall the data from your data store and will want to design your class structure in a way that it can be constructed an deconstructed efficiently. If your specific web application consists of mostly real time data you may want to consider implementing a SQL cache dependency for this data.
• Think about how data will be accessed by your application: Also from your requirements gathering you should have a good understanding of how your objects and the data stored inside your objects will be accessed. You do not necessarily want to look at the best possible way of organizing your classes, rather you want to look at the best way of organizing your classes for your application. For instance, If your data were to be generally requested all at once it may be better stored in one method rather than another method which would be better if the data were to be selected one record at a time. Choosing the right data type is important for your implementation, carefully review you options and use the data type that best suits your needs.
• Use smaller transactions when possible: At this point in the game if you find yourself designing large transactions you may want to reconsider your design pattern. For a high performance web application you should try to minimize the number of transactions it takes to accomplish any given task. For instance in an ecommerce system, if a user were to add an item to his or her cart, this should be one simple transaction. If you find yourself inserting the data into 3 different places and recalculating inventory, then you are doing something wrong.

Data Structure

Now after you have defined your class structure and have done good user requirements gathering you should have a much better idea of how your data model should look. There are already many articles online about data modeling so I am not going to go into too much in this article. For more generalized information on this topic please read Database Design and Modeling Fundamentals. Here are a few extra tips on maintaining good database performance.

• For data that is frequently accessed try to use a model that is good for performance. You will find that by first defining your class model you will not need to define your business rules by the relationships of your tables. It is still a good practice to keep these types of dependencies in your database for integrity sake, but every single relation does not necessarily need to be reflected in your data if it will cause performance to fall off.
• Avoid the need for aggregate functions: Like in designing your class, when designing your database model consider the way your data will be accessed, if at this stage you see that you will need to write aggregate functions for the basic functionality of your web application, you may want to reconsider your model. A key value pair system is nice, but if you need to return search results back on items containing the instances of a certain key value you are going to suffer performance problems.
• Define Database Maintenance Procedures from the start: At this point of the process you will have a much better idea of what data can be safely removed or archived periodically. This is also the best time while decision makers are still engaged in the project to define these types of rules.

In the Building High Performance Web Applications in asp.net: Part II we will review actual implementation. Topics include: Caching, HTML, CSS, Javascript, State Management, Binding, Paging, Searching, Compression, Ajax, Asynchronous Programming and coding Tips and Techniques.