Software Performance and Scalability: A Quantitative Approach
Henry H. Liu
Format: PDF / Kindle (mobi) / ePub
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.
required to be within budget under the pressure of showing proﬁt and return on investment (ROI) as soon as possible. It is required to provide customers with all major functionalities at a minimum. And it is required to meet customer’s expectations on performance and scalability to be usable. While management is responsible for providing sufﬁcient budget to cover personnel, development, test infrastructure, and so on, we, the technical staff (developers, quality assurance engineers, and
support. It typically is an extension to your regular performance testing with more users and larger data sets. As you increase the load, whether it’s measured by the number of users or by the size of the data sets, you may see completely different behaviors with your software than you have seen with previous tests using lighter workloads. For this reason, it’s very necessary to conduct some level of scalability testing, especially when you have gotten all of the low-hanging fruits during the
scalability tests might be conducted only prior to the release. Although this is a brief introduction to agile software development, it should be clear what “agile” elements it is advocating. Usually, you don’t want to performance test every nightly build of the software under development. Testing every build is what the QA team would do. Performance testing a non-QAed build will only end up with duplicating the QA engineer’s work. As a performance engineer, you should focus on performance
get all the formulas for the case without feedback. Note that the symbols with subscript i denote the corresponding metrics for queue node i, whereas the symbols with subscript 0 denote the corresponding metrics at the system level. Out of the formulas presented in Table 4.6, you may already notice that there is a prominent scaling factor between the residence time and the service demand or between the response time and the service time. This is a very important scaling relationship showing how
relationship among the resource utilization, service time, and response time for a single queuing node. 4.9. An OLTP workload consists of a single type of user activity of a Web application deployed on a single Web server, which serves static HTML contents. Statistically, the application requires an average service time of 200 ms on the Web server to process a user transaction. The Web server is shared with multiple applications. Calculate the average response time for the above user scenario