- The Emergence of Web Applications
- Basic Definitions
- The Nature of the Web and Its Challenges
- Performance and Scalability
- Performance
- Scalability
- The Internet Medium
- Wide Audience
- Interactive
- Dynamic
- Always On
- Integrated
- Lack of Complete Control
- Measuring Performance and Scalability
- Measuring Performance
- Beyond Benchmarking
- Measuring Scalability
- Throughput and Price/Performance
- Scalability and Performance Hints
- Think End-to-End
- Scalability Doesn't Equal Performance
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Scalability
Informally, engineers describe the challenge of dealing with large audiences and high demand as a problem of scalability. More specifically, we say that a Web application can scale if it continues to be available and functional at consistent speeds as the number of users and requests continues to grow, even to very high numbers. A provider's inability to deliver a document, such as the Starr report, because of server overload was thus a problem of scalability. Note that this definition has nothing to do with performance. As long as a slow application continues to provide consistent performance in the wake of rising demand, it is classified as scalable!
Now, although scalability is commonly defined strictly as a measurement of resiliency under ever-increasing user load, nobody expects a single instance of an application server on a single machine to accommodate millions of users. Often people consider how well an application can "scale up" by describing how effective it is to add resources, such as more CPUs, more memory, or more disks. An application is considered to scale up well if it requires additional resources at a low rate. For example, if we need to add 300MB RAM per 10 concurrent users on our system, we are in trouble. As I discuss later, this scale-up attribute is often represented as a cost, for example, a cost per concurrent transaction.
Generally, three techniques can be employed to improve scalability:
Increase the resources (bigger machines, more disk, more memory).
Improve the software.
Increase the resources and improve the software.
Although the long-term answer is the third technique, our bias is toward the second. Good design at the beginning of a project is the most cost-effective way to improve scalability. No doubt you will need greater resources to deal with higher demands, but this is never the whole story. Although it can take the purchaser part of the distance, throwing money at the problem cannot ensure scalability. I don't deny the need to spend money at certain points in the process. Rather, I suggest strategic places to spend and strategic opportunities during the design that can give application designers the biggest bang for their buck, thereby reducing their need to purchase more resources than necessary.