- Data Management Alternatives for IIS (webclass) and ASP Application Servers
- Laying the Groundwork
- Measuring Scalability (NOT!)
- Sessions and State
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Measuring Scalability (NOT!)
I'm going to share with you some ideas that I cannot (yet) prove. Consider them to be theories that are based on some experience but not hard measurements. You can judge for yourself whether they make sense.
When you create a network-based application, you are concerned with two numbers. The first(and obvious) one is the total number of users that your application will have. This number will dictate the size of your database or data records. If you expect your system to handle 50000 users, you'll need a database system that can efficiently handle at least that many records, and probably more. If you expect to handle only a handful of users, you might skip the database entirely and store records in individual directories on disk.
The second and less obvious number is the number of users that you expect will be using your application at a given time. For example: you might have a 401K plan tracking system for your company that will need to handle tens of thousands of records. But you can imagine that if all your employees were using that program at once, your company would go bankrupt because nobody would ever get any work done. Such an application may never have more than three or four people accessing the program at any one time. The application may only need to support a few simultaneous users. The number of simultaneous users dictates the amount of bandwidth and server capacity/performance that your site will need.
Large commercial sites, such as Amazon.com, need to support both large numbers of total users and large numbers of simultaneous users. For these kinds of sites you'll need to use every trick in the book, from multiple servers to high-speed networks and database engines. You'll also be able to justify the investment in architecting of your application for MTS or other transactioning layers.
But what about smaller applications?
){kind=link}
Figure 1 illustrates the typical performance of an application as the number of simultaneous users increases. The blue line shows the performance of an ASP or Webclass based application that does not use MTS. The red line shows the performance of the same application using MTS. As you can see, for small numbers of users, the extra layer imposed by MTS actually decreases performance. The efficiency that is provided by tighter control of objects on an MTS system only comes in to play with large systems.
){kind=link}
Figure 2 addresses the issue of cost to develop and run an application. The blue line again shows an application without MTS. The initial cost is lower because it is easier to design and build applications without the added complexity of MTS. The cost increases more quickly, however, as you'll need to add hardware sooner with this approach as the number of simultaneous users increases. The red line illustrates the MTS case, where you have a higher development cost, but your application scales better reducing the need for additional hardware as the number of simultaneous users increases.
Both of these figures do not address additional benefits of MTS in terms of making it easier to manage the transactioning process—especially if your application has complex multi-stage transactions and transaction rollback requirements.
There is one catch to these figures. They don't address the question of "how big is big?" Frankly, I can't answer that. It depends a great deal on your system and application architecture. But it is clear that just as simple approaches do not scale well to larger applications, it is equally true that large scale application techniques do not scale down well to smaller applications.