Designing and Developing for Performance.docx

1、Designing and Developing for PerformanceDesigning and Developing for PerformanceGood system performance begins with design and continues throughout the life of your system. Carefully consider performance issues during the initial design phase, and it will be easier to tune your system during product

2、ion.This chapter contains the following sections: Oracle Methodology Understanding Investment Options Understanding Scalability System Architecture Application Design Principles Workload Testing, Modeling, and Implementation Deploying New ApplicationsOracle MethodologySystem performance has become i

3、ncreasingly important as computer systems get larger and more complex and as the Internet plays a bigger role in business applications. In order to accommodate this, Oracle has produced a performance methodology based on years of designing and performance experience. This methodology explains clear

4、and simple activities that can dramatically improve system performance.Performance strategies vary in their effectiveness, and systems with different purposes, such as operational systems and decision support systems, require different performance skills. This book examines the considerations that a

5、ny database designer, administrator, or performance expert should focus their efforts on.System performance is designed and built into a system. It does not just happen. Performance problems are usually the result of contention for, or exhaustion of, some system resource. When a system resource is e

6、xhausted, the system is unable to scale to higher levels of performance. This new performance methodology is based on careful planning and design of the database, to prevent system resources from becoming exhausted and causing down-time. By eliminating resource conflicts, systems can be made scalabl

7、e to the levels required by the business.Understanding Investment OptionsWith the availability of relatively inexpensive, high-powered processors, memory, and disk drives, there is a temptation to buy more system resources to improve performance. In many situations, new CPUs, memory, or more disk dr

8、ives can indeed provide an immediate performance improvement. However, any performance increases achieved by adding hardware should be considered a short-term relief to an immediate problem. If the demand and load rates on the application continue to grow, then the chance that you will face the same

9、 problem in the near future is very likely.In other situations, additional hardware does not improve the systems performance at all. Poorly designed systems perform poorly no matter how much extra hardware is allocated. Before purchasing additional hardware, make sure that there is no serialization

10、or single threading going on within the application. Long-term, it is generally more valuable to increase the efficiency of your application in terms of the number of physical resources used for each business transaction.Understanding ScalabilityThe word scalability is used in many contexts in devel

11、opment environments. The following section provides an explanation of scalability that is aimed at application designers and performance specialists.What is Scalability?Scalability is a systems ability to process more workload, with a proportional increase in system resource usage. In other words, i

12、n a scalable system, if you double the workload, then the system would use twice as many system resources. This sounds obvious, but due to conflicts within the system, the resource usage might exceed twice the original workload.Examples of bad scalability due to resource conflicts include the follow

13、ing: Applications requiring significant concurrency management as user populations increase Increased locking activities Increased data consistency workload Increased operating system workload Transactions requiring increases in data access as data volumes increase Poor SQL and index design resultin

14、g in a higher number of logical I/Os for the same number of rows returned Reduced availability, because database objects take longer to maintainAn application is said to be unscalable if it exhausts a system resource to the point where no more throughput is possible when its workload is increased. S

15、uch applications result in fixed throughputs and poor response times.Examples of resource exhaustion include the following: Hardware exhaustion Table scans in high-volume transactions causing inevitable disk I/O shortages Excessive network requests, resulting in network and scheduling bottlenecks Me

16、mory allocation causing paging and swapping Excessive process and thread allocation causing operating system thrashingThis means that application designers must create a design that uses the same resources, regardless of user populations and data volumes, and does not put loads on the system resourc

17、es beyond their limits.System ScalabilityApplications that are accessible through the Internet have more complex performance and availability requirements. Some applications are designed and written only for Internet use, but even typical back-office applications, such as a general ledger applicatio

18、n, might require some or all data to be available online.Characteristics of Internet age applications include the following: Availability 24 hours a day, 365 days a year Unpredictable and imprecise number of concurrent users Difficulty in capacity planning Availability for any type of query Multitie

19、r architectures Stateless middleware Rapid development timescale Minimal time for testingFigure2-1 illustrates the classic workload growth curve, with demand growing at an increasing rate. Applications must scale with the increase of workload and also when additional hardware is added to support inc

20、reasing demand. Design errors can cause the implementation to reach its maximum, regardless of additional hardware resources or re-design efforts.Figure 2-1 Workload Growth CurveText description of the illustration pfgrf213.gifApplications are challenged by very short development timeframes with lim

21、ited time for testing and evaluation. However, bad design generally means that at some point in the future, the system will need to be re-architected or re-implemented. If an application with known architectural and implementation limitations is deployed on the Internet, and if the workload exceeds

22、the anticipated demand, then there is real chance of failure in the future. From a business perspective, poor performance can mean a loss of customers. If Web users do not get a response in seven seconds, then the users attention could be lost forever.In many cases, the cost of re-designing a system

23、 with the associated downtime costs in migrating to new implementations exceeds the costs of properly building the original system. The moral of the story is simple: design and implement with scalability in mind from the start.Factors Preventing ScalabilityWhen building applications, designers and a

24、rchitects should aim for as close to perfect scalability as possible. This is sometimes called linear scalability, where system throughput is directly proportional to the number of CPUs.In real life, linear scalability is impossible for reasons beyond a designers control. However, making the applica

25、tion design and implementation as scalable as possible should ensure that current and future performance objectives can be achieved through expansion of hardware components and the evolution of CPU technology.Factors Preventing Linear Scalability1. Poor Application Design, Implementation, and Config

26、uration The application has the biggest impact on scalability. For example: Poor schema design can cause expensive SQL that does not scale. Poor transaction design can cause locking and serialization problems. Poor connection management can cause poor response times and unreliable systems.However, t

27、he design is not the only problem. The physical implementation of the application can be the weak link. For example: Systems can move to production environments with bad I/O strategies. The production environment could use different execution plans than those generated in testing. Memory-intensive a

28、pplications that allocate a large amount of memory without much thought for freeing the memory at runtime can cause excessive memory usage. Inefficient memory usage and memory leaks put a high stress on the operating virtual memory subsystem. This impacts performance and availability. Incorrect Sizi

29、ng of Hardware Components Bad capacity planning of all hardware components is becoming less of a problem as relative hardware prices decrease. However, too much capacity can mask scalability problems as the workload is increased on a system. Limitations of Software Components All software components

30、 have scalability and resource usage limitations. This applies to application servers, database servers, and operating systems. Application design should not place demands on the software beyond what it can handle. Limitations of Hardware Components Hardware is not perfectly scalable. Most multiproc

31、essor machines can get close to linear scaling with a finite number of CPUs, but after a certain point each additional CPU can increase performance overall, but not proportionately. There might come a time when an additional CPU offers no increase in performance, or even degrades performance. This b

32、ehavior is very closely linked to the workload and the operating system setup.Note: These factors are based on Oracle Server Performance groups experience of tuning unscalable systems.System ArchitectureThere are two main parts to a systems architecture: Hardware and Software Components Configuring the Right System Architecture for Your RequirementsHardware and Software ComponentsThis section discusses hardware and software components.Hardware Components