Designing for Scalability
Developers often take one of two extremes with respect to designing for scalability—they don’t support scaling, or they try to support unlimited scaling. In general, developers should focus their effort somewhere in the middle. In other words, they should design and build the application with the expectation that it will scale to a point, possibly beyond their reasonable expectations. It is important to note that most applications do not experience and therefore do not need to support overnight success.
Scaling Up, Scaling Out, or Both
Before you discuss or plan for scaling, you need to understand that there are two ways to scale a solution. First, you can scale an application up (also known as vertical scaling) by moving the application to faster computer resources, such as faster server or faster disk drive. If you have a CPU-intensive application, moving the application to a faster CPU should improve performance. Second, you can scale out an application (also known as horizontal scaling) by rewriting the application to support multiple CPUs (servers) and possibly multiple databases. As a general rule, it normally costs less to run an application on multiple fast servers than on a single very fast server that is four times faster.
Assume, for example, you have an application that makes extensive use of a web service to perform complex processing. Should the web service become a bottleneck, you could host the web service on a faster (scaling up), or you might place the web service onto multiple servers, which the application (or load balancer) may call in a round-robin fashion (scaling out). As shown in FIGURE 19-2, over time, a developer may utilize horizontal and vertical scaling.
FIGURE 19-2 Developers often use vertical and horizontal scaling to meet application demands.
Minimize Objects on Key Pages
Across the web, developers strive for site pages to load in 2 to 3 seconds or less. If a webpage takes too long to load, visitors will simply leave the site. With that in mind, you should take time to evaluate your key site pages, particularly the home page. If possible, reduce the number of objects on the page (graphics, audio, and so on), so that the page loads within an acceptable time range.
Selecting Measurement Points
As you analyze your site with respect to scalability, you will want your efforts to have a maximum performance impact. To begin, you should identify the potential bottlenecks within the system, both with respect to CPU utilization and also with respect to disk and database use. If you scale, for example, part of the system that is not in high demand, your scaling will not significantly impact system performance. As you consider your measurement points, keep the 80/20 rule in mind and strive to locate the 20 percent of your code that performs 80 percent of the processing.
Analyze Your Database Operations
As you have learned, load balancing an application that relies on database operations can be a challenging task due to the application’s need to synchronize database insert and update operations. If your site is like most site, you will find that most of your database operations are read operations that access data, as opposed to write operations that add or update data. Write operations are more complex and require database synchronization.
You may be able to modify your application so that it can distribute the database read operations, especially for data that is not affected by write operations (static data). By distributing your database read operations in this way, you horizontally scale out your application, which may not only improve performance, but also improve resource redundancy.
Evaluate Your System’s Data Logging Requirements
When developers deploy new sites, they often enable a variety of logging capabilities so they can watch for system errors and monitor system traffic. Often, the developers do not turn off the logs. As a result, the log files begin to consume considerable disk space, and the system will utilize CPU processing time updating the log files. As your monitor your system performance, log only those events you must truly measure.
Revisit Your Service-Level Agreement (SLA)
As you plan for your site’s scalability, take time to review your SLA with the cloud-solution provider. The SLA may specify performance measures the provider must maintain, which, in turn, will provide the resources to which your application can scale. As you review the SLA, make sure you take time to understand the numbers or percentages the SLA presents. For example, many solution providers claim 99.9 percent uptime and availability. If you do the math, you will learn that if your site can be down 0.1 percent of the time, that equates to
Many cloud providers, such as Amazon, now provide 11 nines (99.999999999 percent) uptime:
