Scaling Considerations in Active Server Pages

Scaling any application requires efficient use of system resources. Although this is easily stated, many development teams do not properly consider the impact of system resource limitations during an application's design phase.

To understand these limitations, consider a real-world analogy, a hypothetical auto repair shop. The shop starts small, with perhaps a single garage bay and a handful of customers. The small business can easily handle its limited customer load and flourishes in the community. As time goes on, the excellent work done at the shop gains a reputation, and more and more customers seek services from the business. The owners get together and decide that their business must grow. Their goal is to be flexible and expand the business automatically with each new customer. Therefore, they make the ill-fated decision to hire a new mechanic for each new customer they take on. The owners reason that because of the one-to-one relationship between mechanics and customers, every customer will be satisfied and will never have to wait for service from a mechanic.

The experiment, of course, is a failure. The garage facility is not equipped to handle dozens of mechanics working on dozens of cars at the same time. Now the owners face having to purchase a larger garage for all the new mechanics. Since they did not plan on the purchase of a new building and new equipment, the budget does not support the required growth and the business fails.

The answer to the problem is clearly to pool the resources of the garage and a few mechanics to support the load of new customers. Rather than continue to hire mechanics and build garages, the business uses the resources it has as efficiently as possible and continues to grow and prosper. But the lessons obvious in our auto repair shop example are often lost in the business of software design. Most systems face inevitable growth and require intelligent planning and careful resource allocation. Yet how many times does a business get caught having to purchase new hardware to support the latest application?

The problems of scaling software involve three key resources that are analogous to the garage and mechanics in our example. These resources are threads, objects, and ODBC connections, and their management directly affects your site's performance. Microsoft Internet Information Server (IIS) and Microsoft Active Server Pages (ASP) include built-in scaling features that assist in resource management.

Threads are execution points within the memory space of an application. IIS provides multithreading capability to manage users who come to your site simultaneously. However, this capability might or might not be extended to the COM objects called by ASP. Therefore, processing information such as data source updates can be slowed if your business objects are single-threaded—and Visual Basic typically creates only single-threaded business objects.

Object instances also require thoughtful management. Many systems create one instance of a single-threaded business object for each client who calls. This process creates a one-to-one relationship between object instances and application users. This is exactly the same as hiring a mechanic for each new customer and can result in a fatal blow to system resources. MTS solves this problem by creating a pool of object instances which can be shared by all clients.

ODBC connections must also be handled correctly. In many applications, developers open an ODBC connection at the start of a session and close it at the end. Although extremely common in Visual Basic applications, this practice is devastating when trying to scale. A system simply does not have the resources to provide every user with an individual ODBC connection. ASP helps by automatically pooling the connections made to data sources that are accessed with ActiveX Data Objects (ADO). This feature is enabled by the system registry setting shown in Appendix D.

Without the use of any special software such as MTS, Active Server Pages provides reasonable scaling features as long as you perform data access directly from the script in a Web page. This architecture supports multithreading capabilities and ODBC connection pooling, but it presents several problems.

First, ASP is script intensive. When programming data access from an ASP page with ADO, you usually write all code directly into the Web page. This script-intensive style can be terribly difficult to maintain. Script is mixed directly with HTML, potentially resulting in a pile of spaghetti code no one can understand.

Second, script is not reusable. Active Server Pages does not support anything like the binary reusability of a Visual Basic business object. Although ASP can use Visual Basic objects, it cannot create the equivalent of a class module internally. Typically, developers are limited to cut-and-paste, which promotes poor coding practices and produces bulky pages.

Third, script cannot be accessed by other applications. Because script code does not support encapsulation, it cannot be accessed by other applications that might want to perform data access on the same source with the same business rules. Therefore, if you want to access the same data source with a Visual Basic application, you would have to write a separate set of functionality for each new application. This is a terrible waste of time and effort.

In order to create an environment in which any application can access a data source, you need to factor out the common functionality of the business rules and call it from the ASP page. Removing data access from the page and transferring it to a separate business object allows other applications that support the Distributed Component Object Model (DCOM) to reuse the business logic without additional work. Under this scenario, you depend absolutely on a product such as Microsoft Transaction Server to provide the thread, object, and connection pooling necessary to scale the application.