Software Performance and Scalability: A Quantitative Approach (Quantitative Software Engineering Series)

This is one book which can cater for any section of software development work force (school/high school or undergraduate or graduate or instructor or software rofessional). The book is aptly organized and have a upbeat flow of information from beginning to ending. I would say any performance test engineer should read this book before submitting a performance test plan for any application. I would say any software developer should read this book before designing any feature. With my 14 years of experience API profiling is most over looked or given least attention in the initial design and people do patch up at end of the release. The chapter on API profiling framework should be eye opener for many brains. Amdahl's law and the case study speaks volume about the author and his experience. Effective optimization and tuning techniques can be a very handy especially for applications which are years old and still exist. Overall it was a complete quantitative, qualitative, practical approach to performance and scalability. I highly recommend this book to anyone who is serious about performance and scalability. - Bala (Bangalore, India). CHAPTER 1

Hardware Platform

What mathematical problems should a computing machine solve? —Konrad Zuse, 1934

To build new specifications from given specifications by a prescription. —His answer in 1936

Computing is the deviation of result specifications to any specifications by a prescription. —His extended definition in 1946

What performance a software system exhibits often solely depends on the raw speed of the underlying hardware platform, which is largely determined by the central processing unit (CPU) horsepower of a computer. What scalability a software system exhibits depends on the scalability of the architecture of the underlying hardware platform as well. I have had many experiences with customers who reported that slow performance of the software system was simply caused by the use of undersized hardware. It's fair to say that hardware platform is the number one most critical factor in determining the performance and scalability of a software system. We'll see in this chapter the two supporting case studies associated with the Intel® hyperthreading technology and new Intel multicore processor architecture.

As is well known, the astonishing advances of computers can be characterized quantitatively by Moore's law. Intel co-founder Gordon E. Moore stated in his 1965 seminal paper that the density of transistors on a computer chip is increasing exponentially, doubling approximately every two years. The trend has continued for more than half a century and is not expected to stop for another decade at least.

The quantitative approach pioneered by Moore has been very effective in quantifying the advances of computers. It has been extended into other areas of computer and software engineering as well, to help refine the methodologies of developing better software and computer architectures [Bernstein and Yuhas, 2005; Laird and Brennan, 2006; Gabarro, 2006; Hennessy and Patterson, 2007]. This book is an attempt to introduce quantitativeness into dealing with the challenges of software performance and scalability facing the software industry today.

To see how modern computers have become so powerful, let's begin with the Turing machine.

1.1 TURING MACHINE

Although Charles Babbage (1791–1871) is known as the father of computing, the most original idea of a computing machine was described by Alan Turing more than seven decades ago in 1936. Turing was a mathematician and is often considered the father of modern computer science.

As shown in Figure 1.1, a Turing machine consists of the following four basic elements:

• A tape, which is divided into cells, one next to the other. Each cell contains a symbol from some finite alphabet. This tape is assumed to be infinitely long on both ends. It can be read or written.

• A head that can read and write symbols on the tape.

• A table of instructions that tell the machine what to do next, based on the current state of the machine and the symbols it is reading on the tape.

• A state register that stores the states of the machine.

A Turing machine has two assumptions: one is the unlimited storage space and the other is completing a task regardless of the amount of time it takes. As a theoretical model, it exhibits the great power of abstraction to the highest degree. To some extent, modern computers are as close to Turing machines as modern men are close to cavemen. It's so amazing that today's computers still operate on the same principles as Turing proposed seven decades ago. To convince you that this is true, here is a comparison between a Turing machine's basic elements and a modern computer's constituent parts:

• Tape—memory and disks

• Head—I/O controllers (memory bus, disk controllers, and network port)

• Table + state register—CPUs

In the next section, I'll briefly introduce the next milestone in computing history, the von Neumann architecture.

1.2 VON NEUMANN MACHINE

John von Neumann was another mathematician who pioneered in making computers a reality in computing history. He proposed and participated in building a machine named EDVAC (Electronic Discrete Variable Automatic Computer) in 1946. His model is very close to the computers we use today. As shown in Figure 1.2, the von Neumann model consists of four parts: memory, control unit, arithmetic logic unit, and input/output.

Similar to the modern computer architecture, in the von Neumann architecture, memory is where instructions and data are stored, the control unit interprets instructions while coordinating other units, the arithmetic logic unit performs arithmetic and logical operations, and the input/output provides the interface with users.

A most prominent feature of the von Neumann architecture is the concept of stored program. Prior to the von Neumann architecture, all computers were built with fixed programs, much like today's desktop calculators that cannot run Microsoft Office or play video games except for simple calculations. Stored program was a giant jump in making machine hardware be independent of software programs that can run on it. This separation of hardware from software had profound effects on evolving computers.

The latency associated with data transfer between CPU and memory was noticed as early as the von Neumann architecture. It was known as the von Neumann bottleneck, coined by John Backus in his 1977 ACM Turing Award lecture. In order to overcome the von Neumann bottleneck and improve computing efficiency, today's computers add more and more cache between CPU and main memory. Caching at the chip level is one of the many very crucial performance optimization strategies at the chip hardware level and is indispensable for modern computers.

In the next section, I'll give a brief overview about the Zuse machine, which was the earliest generation of commercialized computers. Zuse built his machines independent of the Turing machine and von Neumann machine.

1.3 ZUSE MACHINE

When talking about computing machines, we must mention Konrad Zuse, who was another great pioneer in the history of computing.

In 1934, driven by his dislike of the time-consuming calculations he had to perform as a civil engineer, Konrad Zuse began to formulate his first ideas on computing. He defined the logical architecture of his Z1, Z2, Z3, and Z4 computers. He was completely unaware of any computer-related developments in Germany or in other countries until a very late stage, so he independently conceived and implemented the principles of modern digital computers in isolation.

From the beginning it was clear to Zuse that his computers should be freely programmable, which means that they should be able to read an arbitrary meaningful sequence of instructions from a punch tape. It was also clear to him that the machines should work in the binary number system, because he wanted to construct his computers using binary switching elements. Not only should the numbers be represented in a binary form, but the whole logic of the machine should work using a binary switching mechanism (0–1 principle).

Zuse took performance into account in his designs even from the beginning. He designed a high-performance binary floating point unit in the semilogarithmic representation, which allowed him to calculate very small and very big numbers with sufficient precision. He also implemented a high-performance adder with a one-step carry-ahead and precise arithmetic exceptions handling.

Zuse even funded his own very innovative Zuse KG Company, which produced more than 250 computers with a value of 100 million DM between 1949 and 1969. During his life, Konrad Zuse painted several hundred oil paintings. He held about three dozen exhibitions and sold the paintings. What an interesting life he had!

In the next section, I'll introduce the Intel architecture, which prevails over the other architectures for modern computers. Most likely, you use an Intel architecture based system for your software development work, and you may also deploy your software on Intel architecture based systems for performance and scalability tests. As a matter of fact, I'll mainly use the Intel platform throughout this book for demonstrating software performance optimization and tuning techniques that apply to other platforms as well.

1.4 INTEL MACHINE

Intel architecture based systems are most popular not only for development but also for production. Let's dedicate this section to understanding the Intel architecture based machines.

1.4.1 History of Intel's Chips

Intel started its chip business with a 108 kHz processor in 1971. Since then, its processor family has evolved from year to year through the chain of 4004–8008–8080 –8086–80286–80386–80486–Pentium–Pentium Pro–Pentium II–Pentium III/Xeon–Itanium–Pentium 4/Xeon to today's multicore processors. Table 1.1 shows the history of the Intel processor evolution up to 2005 when the multicore microarchitecture was introduced to increase energy efficiency while delivering higher performance.

1.4.2 Hyperthreading

Intel started introducing its hyperthreading (HT) technology with Pentium 4 in 2002. People outside Intel are often confused about what HTexactly is. This is avery relevant subject when you conduct performance and scalability testing, because you need to know if HT is enabled or not on the systems under test. Let's clarify what HT is here.

First, let's see how a two physical processor system works. With a dual-processor system, the two processors are separated from each other physically with two independent sockets. Each of the two processors has its own hardware resources such as arithmetic logical unit (ALU) and cache. The two processors share the main memory only through the system bus, as shown in Figure 1.3.

As shown in Figure 1.4, with hyperthreading, only a small set of microarchitecture states is duplicated, while the arithmetic logic units and cache(s) are shared. Compared with a single processor without HT support, the die size of a single processor with HT is increased by less than 5%. As you can imagine, HT may slow down single-threaded applications because of the overhead for synchronizations between the two logical processors. However, it is beneficial for multithreaded applications. Of course, a single processor with HT will not be the same as two physical processors without HT from the performance and scalability perspectives for very obvious reasons.

* Case Study 1.1: Intel Hyperthreading Technology

How effective is hyperthreading? I had a chance to test it with a real-world OLTP (online transaction processing) application. The setup consisted of three servers: a Web server, an application server, and a database server. All servers were configured with two single-core Intel® Xeon™ processors at 3.4-GHz with hyperthreading support. The test client machine was on a similar system as well. The details of the application and the workload used for testing are not important here. The intention here is to illustrate how effective hyperthreading is with this specific setup and application.

Figure 1.5 shows the average response times of the workload with and without hyperthreading for different numbers of virtual users. The workload used for the tests consisted of a series of activities conducted by different types of users. The response time measured was from end to end without including the user's own think times. It was averaged over all types of activities.

With this specific test case, the effectiveness of HT depended on the number of users, ranging from 7%, to 23%, and to 33%, for 200, 300, and 400 users, respectively. The maximum improvement of 33% for 400 users is very significant.

As a matter of fact, the effectiveness of HT depends on how busy the systems are without HT when an intended load is applied to the systems under test. If CPUs of a system are relatively idle without HT, then enabling HT would not help improve the system performance much. However, if the CPUs of a system are relatively busy without HT, enabling HT would provide additional computing power, which helps improve the system performance significantly. So the effectiveness of HT depends on whether a system can be driven to its fullest possible utilization.

In order to help prove the above observation on the circumstances under which HT would be effective, Figure 1.6 shows the CPU usages associated with the Web server, application server, and database server for different numbers of users with hyperthreading turned off and on, respectively. I have to explain that those CPU usage numbers were CPU utilizations averaged over the total number of processors perceived by the Microsoft Windows® 2003 Enterprise Edition operating system. With hyperthreading not turned on, the two single-core processors were perceived as two CPUs. However, when hyperthreading was turned on, the two single-core processors were perceived by the operating system as four processors, so the total CPU utilization would be the average CPU utilization multiplied by four and the maximum total CPU utilization would be 400%.

As is seen, the average CPU utilizations with HT turned on were lower than those with HT off. Take the Web server for 200 users as an example. With HT off, the average system CPU utilization was 27%. However, with HT on, the average system CPU utilization turned to 15%. This doesn't mean that the physical CPUs were about twice busier with HT off than with HT on. If we take into account the fact that those CPU utilization numbers were averaged over the total number of CPUs, it means that with HT off, each of the two CPUs of the Web server was 27% busy, whereas with HT on, each of the four CPUs of the same Web server was 15% busy; so overall the four CPUs in the case of HT-enabled did more work than the two CPUs in the case of HT-disabled; thus the overall system performance has been improved.

In the next section, I'll help you understand what Intel's multicore microarchitecture is about. Of course, multicore is a lot more powerful than hyperthreading, since a dual-core processor is closer to two physical processors than a single-core hyperthreaded processor is.

1.4.3 Intel's Multicore Microarchitecture

In contrast to hyperthreading, the Intel multicore microarchitecture shares nothing above L2 cache, as shown in Figure 1.7 for a dual-core configuration. Therefore both single-threaded and multithreaded applications can benefit from the multiple execution cores. Of course, hyperthreading and multicore do not contradict each other, as one can have each core hyperthreading enabled.

The Intel multicore microarchitecture resulted from the marriage of the other two Intel microarchitectures: NetBurst and Mobile, as shown in Figure 1.8. Note that Intel started to enter the most lucrative market of high-end server systems as early as Pentium Pro. That's how the NetBurst microarchitecture was born with the Xeon family of processors. The Mobile microarchitecture was introduced to respond to the overheated mobile computing demands, for which low-power consumption was one of the most critical requirements. Combining the advantages of high performance from NetBurst and low power consumption from Mobile resulted in the new Intel multicore microarchitecture.

It's very necessary to differentiate among those three terms of architecture, microarchitecture, and processor:

• Processor architecture refers to the instruction set, registers, and memory data-resident data structure that is public to the programmer. Processor architecture maintains instruction set compatibility so that processors will run the programs written for generations of processors.

• Microarchitecture refers to the implementation of processor architecture in silicon.

• Processors are productized implementation of microarchitecture.

For software performance and scalability tests, one always needs to know the detailed specs of the systems being tested, especially the details of the processors as the brain of a system. It actually takes time to learn all about Intel processors. Here is a more systematic approach to pursuing the details of the Intel processors used in an Intel architecture based system. One should start with the processor number, which uniquely identifies each release of the Intel processors. It's not enough just to know the marketing names of the Intel processors. If you are using Intel architecture based systems for your performance and scalability tests, it's very likely that you are using Intel Xeon processor based systems.
(Continues...) Excerpted from Software Performance and Scalability by Henry H. Liu. Copyright © 2009 IEEE Computer Society. Excerpted by permission of John Wiley & Sons.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site. Software Performance and Scalability......Page 5 Contents......Page 9 PREFACE......Page 17 ACKNOWLEDGMENTS......Page 23 Performance versus Scalability......Page 25 PART 1 THE BASICS......Page 27 1. Hardware Platform......Page 29 1.1 Turing Machine......Page 30 1.2 von Neumann Machine......Page 31 1.3 Zuse Machine......Page 32 1.4.2 Hyperthreading......Page 33 1.4.3 Intel’s Multicore Microarchitecture......Page 37 1.5 Sun Machine......Page 41 1.6.1 Processors......Page 42 1.6.2 Motherboard......Page 43 1.6.3 Chipset......Page 44 1.6.4 Storage......Page 46 1.6.5 RAID......Page 48 1.6.6 Networking......Page 51 1.6.7 Operating System......Page 53 1.7.1 Memory Leaks......Page 54 1.8 Sizing Hardware......Page 59 Recommended Reading......Page 61 Exercises......Page 62 2. Software Platform......Page 65 2.1 Software Stack......Page 66 2.2 APIs......Page 68 2.2.2 Java APIs......Page 69 2.2.3 Google APIs......Page 70 2.3 Multithreading......Page 71 2.4.1 Systems Software......Page 77 2.4.2 Application Software......Page 78 2.5.1 What Is Enterprise Software?......Page 79 2.5.3 Monolithic Architecture......Page 81 2.5.4 Client/Server Architecture......Page 82 2.5.5 Three-Tier Architecture......Page 83 2.5.6 N-Tier Architecture......Page 84 2.5.8 Service-Oriented Architecture......Page 85 2.6 Summary......Page 87 Exercises......Page 88 3. Testing Software Performance and Scalability......Page 89 3.1 Scope of Software Performance and Scalability Testing......Page 91 3.1.1 Performance Regression Testing......Page 92 3.1.2 Performance Optimization and Tuning Testing......Page 94 3.1.4 Scalability Testing......Page 99 3.1.6 Additional Merits of Performance Testing......Page 106 3.2.1 Agile Software Development......Page 107 3.2.2 Extreme Programming......Page 108 3.3 Defining Software Performance......Page 110 3.3.1 Performance Metrics for OLTP Workloads......Page 111 3.3.2 Performance Metrics for Batch Jobs......Page 116 3.4 Stochastic Nature of Software Performance Measurements......Page 119 3.5 Amdahl’s Law......Page 121 3.6 Software Performance and Scalability Factors......Page 123 3.6.1 Hardware......Page 124 3.6.2 Operating System......Page 127 3.6.3 Database Statistics......Page 131 3.6.4 SQL Server Parameterization......Page 132 3.6.6 Licensing......Page 134 3.7 System Performance Counters......Page 135 3.7.1 Windows Performance Console......Page 136 3.7.2 Using perfmon to Diagnose Memory Leaks......Page 142 3.7.3 Using perfmon to Diagnose CPU Bottlenecks......Page 143 3.7.4 Using perfmon to Diagnose Disk I/O Bottlenecks......Page 145 3.7.5 Using Task Manager to Diagnose System Bottlenecks......Page 149 3.7.6 UNIX Platforms......Page 152 3.8 Software Performance Data Principles......Page 153 3.9 Summary......Page 155 Recommended Reading......Page 156 Exercises......Page 157 PART 2 APPLYING QUEUING THEORY......Page 159 4. Introduction to Queuing Theory......Page 161 4.1 Queuing Concepts and Metrics......Page 163 4.1.1 Basic Concepts of Queuing Theory......Page 164 4.1.2 Queuing Theory: From Textual Description to Mathematical Symbols......Page 165 4.2.1 Random Variables and Distribution Functions......Page 167 4.2.2 Discrete Distribution and Probability Distribution Series......Page 168 4.3 Applying Probability Theory to Queuing Systems......Page 169 4.3.1 Markov Process......Page 170 4.3.2 Poisson Distribution......Page 172 4.3.3 Exponential Distribution Function......Page 174 4.3.5 Queuing Node versus Queuing System......Page 176 4.4 Queuing Models for Networked Queuing Systems......Page 177 4.4.1 Queuing Theory Triad I: Response Time, Throughput, and Queue Length (Little’s Law)......Page 178 4.4.2 M/M/1 Model (Open)......Page 179 4.4.4 Queuing Theory Triad II: Utilization, Service Time, and Response Time......Page 183 4.4.5 Multiple Parallel Queues versus Single-Queue Multiple Servers......Page 184 4.4.6 M/M/m/N/N Model (Closed)......Page 186 4.4.7 Finite Response Time in Reality......Page 190 4.4.8 Validity of Open Models......Page 193 4.4.9 Performance and Scalability Bottlenecks in a Software System......Page 194 4.4.10 Genealogy of Queuing Models......Page 195 4.5 Summary......Page 196 Recommended Reading......Page 198 Exercises......Page 199 5. Case Study I: Queuing Theory Applied to SOA......Page 201 5.1 Introduction to SOA......Page 202 5.2 XML Web Services......Page 203 5.3 The Analytical Model......Page 205 5.4 Service Demand......Page 207 5.4.2 XML SOAP Serialization/Deserialization......Page 208 5.4.3 Network Latency......Page 209 5.4.5 Database Server......Page 210 5.4.6 Data Storage......Page 211 5.5.1 Exposing a Stateless Session EJB as an XML Web Service......Page 212 5.6 MedRec Deployment and Test Scenario......Page 213 5.7 Test Results......Page 215 5.7.1 Overhead of the XML Web Services Handle......Page 216 5.7.2 Effects of Caching Web Services Handle......Page 217 5.7.3 Throughput Dynamics......Page 218 5.7.4 Bottleneck Analysis......Page 219 5.8 Comparing the Model with the Measurements......Page 222 5.10 Summary......Page 224 Recommended Reading......Page 225 Exercises......Page 226 6. Case Study II: Queuing Theory Applied to Optimizing and Tuning Software Performance and Scalability......Page 229 6.1.1 Characterizing Performance and Scalability Problems......Page 231 6.1.2 Isolating Performance and Scalability Factors......Page 232 6.1.3 Applying Optimization and Tuning......Page 239 6.2 Effective Optimization and Tuning Techniques......Page 244 6.2.1 Wait Events and Service Demands......Page 245 6.2.2 Array Processing—Reducing V(i)......Page 247 6.2.3 Caching—Reducing Wait Time (W(i))......Page 250 6.2.4 Covering Index—Reducing Service Demand (D(i))......Page 252 6.2.5 Cursor-Sharing—Reducing Service Demand (D(i))......Page 253 6.2.6 Eliminating Extraneous Logic—Reducing Service Demand (D(i))......Page 255 6.2.7 Faster Storage—Reducing Data Latency (W(i))......Page 256 6.2.8 MPLS—Reducing Network Latency (W(i))......Page 257 6.2.9 Database Double Buffering—An Anti Performance and Scalability Pattern......Page 259 6.3 Balanced Queuing System......Page 264 6.4 Summary......Page 268 Recommended Reading......Page 269 Exercises......Page 270 PART 3 APPLYING API PROFILING......Page 273 7. Defining API Profiling Framework......Page 275 7.1 Defense Lines Against Software Performance and Scalability Defects......Page 276 7.2 Software Program Execution Stack......Page 277 7.3 The PerfBasic API Profiling Framework......Page 278 7.3.1 API Profile Logging Format......Page 279 7.3.2 Performance Log Parser......Page 280 7.3.3 Performance Maps......Page 282 7.4 Summary......Page 284 Exercises......Page 285 8. Enabling API Profiling Framework......Page 287 8.1 Overall Structure......Page 288 8.2 Global Parameters......Page 289 8.4 Processing Files......Page 290 8.5 Enabling Profiling......Page 291 8.6 Processing Inner Classes......Page 294 8.7 Processing Comments......Page 295 8.8 Processing Method Begin......Page 296 8.9 Processing Return Statements......Page 298 8.10 Processing Method End......Page 299 8.11 Processing Main Method......Page 300 8.12 Test Program......Page 301 Recommended Reading......Page 303 Exercises......Page 304 9.1 Graphics Tool—dot......Page 305 9.2 Graphics Tool—ILOG......Page 308 9.3 Graphics Resolution......Page 310 9.4.1 driver......Page 311 9.4.2 Global Parameters......Page 313 9.4.3 logReader......Page 315 9.4.4 logWriter......Page 316 9.4.6 Link......Page 317 9.4.8 utility......Page 318 9.4.9 parser......Page 319 9.4.10 xmlProcessor......Page 322 9.4.11 analyzer......Page 323 9.5 Summary......Page 324 Exercises......Page 325 10. Case Study: Applying API Profiling to Solving Software Performance and Scalability Challenges......Page 327 10.1 Enabling API Profiling......Page 328 10.1.1 Mechanism of Populating Log Entry......Page 329 10.1.3 Setting apf.properties File......Page 330 10.1.4 Parsing Workflow......Page 332 10.1.5 Verifying the Profiling-Enabled Source Code......Page 334 10.1.6 Recommended Best Coding Practices......Page 335 10.1.7 Enabling Non-Java Programs......Page 336 10.2.1 Generating API Profiling Log Data......Page 337 10.2.2 Parsing API Profiling Log Data......Page 338 10.2.3 Generating Performance Maps......Page 340 10.2.4 Making Sense Out of Performance Maps......Page 343 10.3.1 Using Adapter to Transform Custom Logs......Page 344 10.3.2 Generating Performance Maps with Custom Logs......Page 345 10.4.1 Client Side Performance Map......Page 349 10.4.2 Server Side Performance Map......Page 351 10.5.1 Baseline......Page 357 10.5.2 Optimization......Page 359 10.5.3 Analysis......Page 360 10.6 Summary......Page 361 Exercises......Page 362 A.1.1 Random Variables......Page 363 A.1.2 Random Variable Vector......Page 364 A.1.3 Independent and Identical Distributions (IID)......Page 365 A.1.5 Processes with Stationary Independent Increments......Page 366 A.2.3 Markov Processes......Page 367 A.3.1 Transition Probability Matrix and C-K Equations......Page 369 A.3.2 State Probability Matrix......Page 371 A.3.3 Classification of States and Chains......Page 372 A.4.2 Transition Rate Matrix......Page 373 A.4.3 Imbedded Markov Chains......Page 374 A.5.1 Definition......Page 375 A.5.2 Limiting State Probabilities......Page 377 A.5.4 Ergodic Theorems for Discrete-Time Markov Chains......Page 378 A.5.5 Ergodic Theorems for Continuous-Time Markov Chains......Page 380 A.6.1 Transition Rate Matrix......Page 381 A.6.2 C–K Equations......Page 382 A.6.4 Ergodicity......Page 383 APPENDIX B MEMORYLESS PROPERTY OF THE EXPONENTIAL DISTRIBUTION......Page 385 C.1 Review of Birth–Death Chains......Page 387 C.2 Utilization and Throughput......Page 388 C.4 Average System Time......Page 389 C.5 Average Wait Time......Page 390 INDEX......Page 391

Praise from the Reviewers:

"The practicality of the subject in a real-world situation distinguishes this book from others available on the market."

—Professor Behrouz Far, University of Calgary

"This book could replace the computer organization texts now in use that every CS and CpE student must take. . . . It is much needed, well written, and thoughtful."

—Professor Larry Bernstein, Stevens Institute of Technology

A distinctive, educational text onsoftware performance and scalability

This is the first book to take a quantitative approach to the subject of software performance and scalability. It brings together three unique perspectives to demonstrate how your products can be optimized and tuned for the best possible performance and scalability:

• The Basics—introduces the computer hardware and software architectures that predetermine the performance and scalability of a software product as well as the principles of measuring the performance and scalability of a software product

• Queuing Theory—helps you learn the performance laws and queuing models for interpreting the underlying physics behind software performance and scalability, supplemented with ready-to-apply techniques for improving the performance and scalability of a software system

• API Profiling—shows you how to design more efficient algorithms and achieve optimized performance and scalability, aided by adopting an API profiling framework (perfBasic) built on the concept of a performance map for drilling down performance root causes at the API level

Software Performance and Scalability gives you a specialized skill set that will enable you to design and build performance into your products with immediate, measurable improvements. Complemented with real-world case studies, it is an indispensable resource for software developers, quality and performance assurance engineers, architects, and managers. It is anideal text for university courses related to computer and software performance evaluation and can also be used to supplement a course in computer organization or in queuing theory for upper-division and graduate computer science students.

Praise from the Reviewers: "The practicality of the subject in a real-world situation distinguishes this book from others available on the market." --Professor Behrouz Far, University of Calgary "This book could replace the computer organization texts now in use that every CS and CpE student must take. . . . It is much needed, well written, and thoughtful." --Professor Larry Bernstein, Stevens Institute of Technology A distinctive, educational text onsoftware performance and scalability This is the first book to take a quantitative approach to the subject of software performance and scalability. It brings together three unique perspectives to demonstrate how your products can be optimized and tuned for the best possible performance and scalability: The Basics--introduces the computer hardware and software architectures that predetermine the performance and scalability of a software product as well as the principles of measuring the performance and scalability of a software product Queuing Theory--helps you learn the performance laws and queuing models for interpreting the underlying physics behind software performance and scalability, supplemented with ready-to-apply techniques for improving the performance and scalability of a software system API Profiling--shows you how to design more efficient algorithms and achieve optimized performance and scalability, aided by adopting an API profiling framework (perfBasic) built on the concept of a performance map for drilling down performance root causes at the API level Software Performance and Scalability gives you a specialized skill set that will enable you to design and build performance into your products with immediate, measurable improvements. Complemented with real-world case studies, it is an indispensable resource for software developers, quality and performance assurance engineers, architects, and managers. It is anideal text for university courses related to computer and software performance evaluation and can also be used to supplement a course in computer organization or in queuing theory for upper-division and graduate computer science students.