Scribd
Upload
205 views

Cloud Computing Chapter 19

This document discusses scalability and capacity planning in cloud computing applications. It defines scalability as an application's ability to dynamically add or remove resources based on user demand. The document compares scaling up (adding more powerful resources) versus scaling out (adding more servers). It emphasizes that complexity reduces scalability and provides examples of tools to monitor applications and measure performance.

Uploaded by

ghar_dash
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
205 views

Cloud Computing Chapter 19

This document discusses scalability and capacity planning in cloud computing applications. It defines scalability as an application's ability to dynamically add or remove resources based on user demand. The document compares scaling up (adding more powerful resources) versus scaling out (adding more servers). It emphasizes that complexity reduces scalability and provides examples of tools to monitor applications and measure performance.

Uploaded by

ghar_dash
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 31

Cloud Computing

Chapter 19 Application Scalability

Learning Objectives

Define and describe scalability. Define and describe the Pareto principle. Compare and contrast scaling up and scaling out. Understand how the law of diminishing returns applies to the scalability process. Describe the importance of understanding a sites database read/write ratio. Compare and contrast scalability and capacity planning. Understand how complexity can reduce scalability.

Scalability
An applications ability to add or remove resources dynamically based on user demand. One of the greatest advantages of cloud-based applications is their ability to scale. Anticipating user demand is often a best guess process. Developers often cannot accurately project the demand, and frequently they released too few or too many resources.

The Pareto Principle (80/20 Rule)


Whether you are developing code, monitoring system utilization, or debugging an application, you need to consider the Pareto principle, also known as the 80/20 rule, or the rule of the vital few and the trivial many. 80 percent of system use comes from 20 percent of the users.

Examples of the Pareto Principle


80 percent of development time is spent on 20 percent of the code. 80 percent of errors reside in 20 percent of the code. 80 percent of CPU processing time is spent within 20 percent of the code.

Load Balancing
Cloud-based solutions should scale on demand. If an applications user demand reaches a specific threshold, one or more servers should be added dynamically to support the application. The load-balancing server distributes workload across an applications server resources.

Load Balancing Continued


The load-balancing server receives client requests and distributes each request to one of the available servers. To determine which server gets the request, the load balancer may use a roundrobin technique, a random algorithm, or a more complex technique based upon each servers capacity and current workload.

Real World: Ganglia Monitoring System


If you are using Linux-based servers, you should consider deploying the Ganglia Monitoring System to monitor your system use. Ganglia is an open-source project created at the University of California, Berkeley. The software monitors and graphically displays the system utilization.

Designing for Scalability


Often developers take one of two extremes with respect to designing for scalabilitythey do not support scaling or they try to support unlimited scaling.

Scaling Up or Out
There are two ways to scale a solution.
You can scale up an application (known as vertical scaling) by moving the application to faster computer resources, such as a faster server or disk drive. If you have a CPU-intensive application, moving the application to a faster CPU should improve performance. You can scale out an application (known as horizontal scaling) by rewriting the application to support multiple CPUs (servers) and possibly multiple databases. As a rule, normally it costs less to run an application on multiple servers than on a single server that is four times as fast.

Scaling over Time


Developers often use vertical and horizontal scaling to meet application demands.

Real World: WebPageTest


Before you consider scaling, you should understand your system performance and potential system bottlenecks. webpagetest.org evaluates your site and creates a detailed report. The report helps you identify images you can further compress and the impact of your system caches, as well as potential benefits of compressing text.

Minimize Objects on Key Pages


Across the Web, developers strive for site pages that load in 2 to 3 seconds or less. If a web page takes too long to load, visitors will simply leave the site. You should 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.

Selecting Measurement Points


As you analyze your site with respect to scalability, you will want your efforts to have a maximum performance impact. Identify the potential bottlenecks both with respect to CPU and database use. If you scale part of the system that is not in high demand, your scaling will not significantly affect system performance. Keep the 80/20 rule in mind and strive to identify the 20 percent of your code that performs 80 percent of the processing.

Real World: Alertra Website Monitoring


Often, system administrators do not know that a site has gone down until a user contacts them. Alertra provides a website monitoring service. When it detects a problem, it sends an e-mail or text message to the sites administrative team. Companies can schedule Alertra to perform its system checks minute-by-minute or hourly.

Analyze Your Database Operations


Load balancing an application that relies on database operations can be challenging, due to the applications need to synchronize database insert and update operations. Within most sites, most of the database operations are read operations, which access data, as opposed to write operations, which add or update data. Write operations are more complex and require database synchronization.

Databases Continued
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.

Real World: Pingdom Website Monitoring


Pingdom provides real-time site monitoring with alert notification and performance monitoring. It notifies you in the event of system downtime and provides performance reports based on your sites responsiveness. Pingdom provides tools you can use to identify potential bottlenecks on your site.

Evaluate Your Systems Data Logging Requirements


When developers deploy new sites, often they enable various logging capabilities so they can watch for system errors and monitor system traffic. Frequently, they do not turn off the logs. As a result, the log files consume considerable disk space, and the system utilizes CPU processing time updating the files. As you monitor your system performance, log only those events you truly must measure.

Real World: Gomez Web Performance Benchmarks


Often developers want to compare their sites benchmarks with those of other sites. Gomez provides site benchmarking for web and mobile applications. It provides cross-browser testing as well as load testing. Gomez also performs real-user monitoring, which focuses on the user experience with respect to the browser influence, geographic location, communication speed, and more.

Revisit Your Service-Level Agreement


As you plan for your sites scalability, take time to review your service-level agreement (SLA) with the cloud-solution provider. The SLA may specify performance measures that the provider must maintain, which, in turn, provides the resources to which your application can scale. As you review your SLA, make sure you understand the numbers or percentages it presents.

Capacity Planning Versus Scalability


Scalability defines a systems ability to use additional resources to meet user demand. Capacity planning defines the resources your application will need at a specific time. The two terms are related, yet different.

Capacity Planning Versus Scalability Continued


When your first design a system, for example, you might plan for 10,000 users accessing the system between 6:00 a.m. and 6:00 p.m. Starting with your user count, you can then determine the number of servers needed, the bandwidth requirements, the necessary disk space, and so on. Meaning, you can determine the capacity your system needs to operate. When user demand exceeds the system capacity, you must scale the system by adding resources.

Scalability and Diminishing Returns


If an application is designed to scale (vertical, or scaling up to faster resources is easy), the question becomes How many resources are enough? Keep in mind that you will start a scaling process to meet performance requirements based upon user demand. At first, adding a faster processor, more servers, or increased bandwidth should have measurable system performance improvements.

Scalability and Diminishing Returns Continued


However, you will reach a point of diminishing returns, when adding additional resources does not improve performance. At that point, you should stop scaling.

Performance Tuning
Your goal is to maximize system performance. By scaling resources, you will, to a point, increase performance. In addition to managing an applications resource utilization, developers must examine the application itself, beginning with the program code and including the objects used, such as graphics and the applications use of caching.

Performance Tuning Continued


To start the process, look for existing or potential system bottlenecks. After you correct those, you should focus on the 20 percent of the code that performs 80 percent of the processingwhich will provide you the biggest return on your system tuning investment.

Complication Is the Enemy of Scalability


As complexity within a system increases, so too does the difficulty of maintaining the underlying code, as well as the overhead associated with the complex code. Furthermore, as an applications complexity increases, its ability to scale usually decreases. When a solution begins to get complex, it is worth stopping to evaluate the solution and the current design.

Real World: Keynote Cloud Monitoring


Keynote is one of the worlds largest third-party monitors of cloud and mobile applications. The company performs more than 100 billion site measurements each year. Keynote uses thousands of measurements that come from computers dispersed across the globe. In addition to providing notification of site downtime, Keynote provides a real-time performance dashboard.

Key Terms

Chapter Review
1. Define scalability. 2. List five to ten potential relationships that align with the Pareto principle, such as how 80 percent of sales come from 20 percent of customers. 3. Compare and contrast vertical and horizontal scaling. 4. Explain the importance of the database read/write ratio. 5. Assume a site guarantees 99.99 percent uptime. How many minutes per year can the site be down?

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy