Application Partitioning

Review the basics of application partitioning

You can use many techniques to build scalable Web applications, but all rely on an old technique—application partitioning. In the days when memory was expensive, developers broke applications into small parts by using overlays to load various parts of the application into memory. Developers use the same method now with bigger applications. For example, you can partition one type of application, such as a customer service application, across multiple servers and reduce the load on individual servers. Microsoft's Network Load Balancing (NLB) and other load-balancing products let you implement application partitioning solutions.

Partitioning applications is one way to spread the load. Another way is to divide your database into one or more databases so that you can also divide large tables into smaller tables. SQL Server 2000 and SQL Server 7.0 both support partitioning tables. In SQL Server 7.0, you need to manually set up partitioning, then create views to work with the partitioned tables. SQL Server 2000's federated database feature makes partitioning easier. When you partition a table, you split it into two or more tables, which you can update and access faster than one larger table. The individual tables might be in the same database. For applications that support very heavy loads, you can put each table in a separate database on its own server. Then your database load is effectively split across multiple tables or, in the latter case, multiple servers.

You can partition a table horizontally by splitting the table into multiple tables. You can also partition tables vertically by splitting the table along columns. For example, you could split the Orders table by placing the customer data in a separate table. When you partition tables, you need to take into account how users will access the tables. For example, users might need to use a join or complex join to access the appropriate data from the tables. Your code also needs to accommodate inserts and updates to the tables by determining which table is the target for the update or insert operations.

Application code partitioning, which links directly to application partitioning, can take several forms. You can use include files and script classes to partition code into blocks. This method gets the code out of the Active Server Pages (ASP) files and positions you to take advantage of forthcoming Microsoft products because you'll be able to move those scripts into COM. Moving code into ASP include files can ease the development process but might cause your application to run slower. Moving the code into COM components will generally make the application perform better.

You can also use COM to partition your code. When you create COM classes, you're essentially creating code libraries that you can use from any COM-ready script or application. You can access the COM classes in a modular way, which presents several advantages. First, you can use COM+ or Microsoft Transaction Server (MTS) to manage the COM components (which contain the classes) and take advantage of the scaling features of both COM+ and MTS. COM+ and MTS enhance component scalability by handling the component instantiation. Second, developers can use methods in the classes without knowing the complexities of the code within, which is one reason for using COM: It lets you encapsulate, or hide, the code in a class. Third, you can easily reuse these COM classes from your script code or from other classes or other code.

By moving your code into COM classes, you're planning for the future. Microsoft will release Application Center Server 2000 (AppCenter Server) later this year. One of AppCenter Server's key features is Component Load Balancing (CLB). CLB is a load-balancing service for COM+ components. At its simplest, CLB is a traffic manager for component requests. When CLB receives a request from an application to use a class, CLB routes that request to the least busy server that provides that component. CLB lets you build clusters of COM+ servers that distribute the processing load dynamically across the servers. CLB also provides fault tolerance. If a server can't supply a component request, CLB automatically reroutes that request to another server. If you partition your code into COM components now, you can take advantage of CLB by simply moving your components to other servers and configuring CLB. The key to partitioning is being able to move parts of an application to other servers without reconfiguring the application. Figure 1, page 72, illustrates how CLB works at the basic level. Each of the Web servers runs AppCenter Server and works as the traffic manager. When a request for a component occurs from an application on the Web server, CLB determines which of the CLB servers to execute the request on.

To work effectively in CLB or any Web application, COM components need to be machine neutral. In other words, the component's code shouldn't reference the particular server it runs on, nor should it access any server-specific features such as the path of the Temp folder or the server name.

COM components can also play a key role in table partitioning. You can use COM to hide the complexity of a database by creating methods in your classes that execute data access to the tables and mask the database structure from the developers. For example, you can create a RetrieveSalesHistory method that retrieves sales history by year. The method's developer is responsible for implementing the code to retrieve the sales history from all the subordinate tables. With this method, the application developers deal with the sales history, and the developer of the RetrieveSalesHistory method deals with the table structure's complexity.

Using application partitioning also lets you gracefully upgrade the application. For example, if you use the RetrieveSalesHistory method, and 6 months from now you develop a new technique for improving performance or data storage, then you need to update only the methods that implement the data-access functions for the sales history. However, you need to consider the maintenance consequences of your choices in application architecture. Using partitioned tables requires maintenance routines. For example, if you use sales history tables that are split by year, you'll need to implement a process to move data from the current sales table to the appropriate history table.

For more information about partitioning SQL Server tables, look up Partitioning, Overview in SQL Server Books Online (BOL). Also, see "Using Views with Partitioned Data" in BOL. For more information about CLB, go to http://www.microsoft.com/applicationcenter/.