Solving Enterprise Applications Performance Puzzles E-Book

Leonid Grinshpan

• Herausgeber: John Wiley & Sons
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 254

Veröffentlichungsjahr: 2012

Beschreibung

Poorly performing enterprise applications are the weakest links in a corporation's management chain, causing delays and disruptions of critical business functions. This groundbreaking book frames enterprise application performance engineering not as an art but as applied science built on model-based methodological foundation. The book introduces queuing models of enterprise application that visualize, demystify, explain, and solve system performance issues. Analysis of these models will help to discover and clarify unapparent connections and correlations among workloads, hardware architecture, and software parameters.

Leseprobe

Table of Contents

Cover

Series page

Title page

Copyright page

Acknowledgments

Preface

WHY I WROTE THIS BOOK

SUBJECT

AUDIENCE

ORGANIZATION

CHAPTER 1 Queuing Networks as Applications Models

1.1. ENTERPRISE APPLICATIONS—WHAT DO THEY HAVE IN COMMON?

1.2. KEY PERFORMANCE INDICATOR—TRANSACTION TIME

1.3. WHAT IS APPLICATION TUNING AND SIZING?

1.4. QUEUING MODELS OF ENTERPRISE APPLICATION

1.5. TRANSACTION RESPONSE TIME AND TRANSACTION PROFILE

1.6. NETWORK OF HIGHWAYS AS AN ANALOGY OF THE QUEUING MODEL

TAKE AWAY FROM THE CHAPTER

CHAPTER 2 Building and Solving Application Models

2.1. BUILDING MODELS

2.2. ESSENTIALS OF QUEUING NETWORKS THEORY

2.3. SOLVING MODELS

2.4. INTERPRETATION OF MODELING RESULTS

TAKE AWAY FROM THE CHAPTER

CHAPTER 3 Workload Characterization and Transaction Profiling

3.1. WHAT IS APPLICATION WORKLOAD?

3.2. WORKLOAD CHARACTERIZATION

3.3. BUSINESS PROCESS ANALYSIS

3.4. MINING TRANSACTIONAL DATA FROM PRODUCTION APPLICATIONS

TAKE AWAY FROM THE CHAPTER

CHAPTER 4 Servers, CPUs, and Other Building Blocks of Application Scalability

4.1. APPLICATION SCALABILITY

4.2. BOTTLENECK IDENTIFICATION

TAKE AWAY FROM THE CHAPTER

CHAPTER 5 Operating System Overhead

5.1. COMPONENTS OF AN OPERATING SYSTEM

5.2. OPERATING SYSTEM OVERHEAD

TAKE AWAY FROM THE CHAPTER

CHAPTER 6 Software Bottlenecks

6.1. WHAT IS A SOFTWARE BOTTLENECK?

6.2. MEMORY BOTTLENECK

6.3. THREAD OPTIMIZATION

6.4. OTHER CAUSES OF SOFTWARE BOTTLENECKS

TAKE AWAY FROM THE CHAPTER

CHAPTER 7 Performance and Capacity of Virtual Systems

7.1. WHAT IS VIRTUALIZATION?

7.2. HARDWARE VIRTUALIZATION

7.3. METHODOLOGY OF VIRTUAL MACHINES SIZING

TAKE AWAY FROM THE CHAPTER

CHAPTER 8 Model-Based Application Sizing: Say Good-Bye to Guessing

8.1. WHY MODEL-BASED SIZING?

8.2. A MODEL’S INPUT DATA

8.3. MAPPING A SYSTEM INTO A MODEL

8.4. MODEL DELIVERABLES AND WHAT-IF SCENARIOS

TAKE AWAY FROM THE CHAPTER

CHAPTER 9 Modeling Different Application Configurations

9.1. GEOGRAPHICAL DISTRIBUTION OF USERS

9.2. ACCOUNTING FOR THE TIME ON END-USER COMPUTERS

9.3. REMOTE TERMINAL SERVICES

9.4. CROSS-PLATFORM MODELING

9.5. LOAD BALANCING AND SERVER FARMS

9.6. TRANSACTION PARALLEL PROCESSING MODELS

TAKE AWAY FROM THE CHAPTER

Glossary

References

Index

IEEE Press

445 Hoes Lane

Piscataway, NJ 08854

IEEE Press Editorial Board

Lajos Hanzo, Editor in Chief

R. AbhariM. El-HawaryO. P. MalikJ. AndersonB-M. HaemmerliS. NahavandiG. W. ArnoldM. LanzerottiT. SamadF. CanaveroD. JacobsonG. Zobrist

Kenneth Moore, Director of IEEE Book and Information Services (BIS)

Copyright © 2012 by the Institute of Electrical and Electronics Engineers.

Published by John Wiley & Sons, Inc., Hoboken, New Jersey. All rights reserved.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, [phone], fax [phone], or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, [phone], fax [phone], or online at http://www.wiley.com/go/permissions.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at [phone], outside the United States at [phone] or fax [phone].

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our website at www.wiley.com.

Library of Congress Cataloging-in-Publication Data:

Grinshpan, L. A. (Leonid Abramovich)

Solving enterprise applications performance puzzles : queuing models to the rescue / Leonid Grinshpan. – 1st ed.

p. cm.

 ISBN 978-1-118-06157-2 (pbk.)

 ISBN 978-1-118-16189-0 (epdf)

 ISBN 978-1-118-16190-6 (mobi)

 ISBN 978-1-118-16191-3 (epub)

1. Queuing theory. I. Title.

 T57.9.G75 2011

 658.4'034–dc23

2011020123

Acknowledgments

My career as a computer professional started in the USSR in the 1960s when I was admitted to engineering college and decided to major in an obscure area officially called “Mathematical and Computational Tools and Devices.” Time proved that I made the right bet—computers became the major driver of civilization’s progress, and (for better or for worse) they have developed into a vital component of our social lives. As I witnessed permanent innovations in my beloved occupation, I was always intrigued by the question: What does it take for such a colossal complex combination of hardware and software to provide acceptable services to its users (which is the ultimate goal of any application, no matter what task it carries out), what is its architecture, software technology, user base, etc.? My research lead me to queuing theory; in a few years I completed a dissertation on queuing models of computer systems and received a Ph.D. from the Academy of Science of the USSR.

Navigating the charted and uncharted waters of science and engineering, I wrote many articles on computer system modeling that were published in leading Soviet scientific journals and reprinted in the United States, as well as a book titled Mathematical Methods for Queuing Network Models of Computer Systems. I contributed to the scientific community by volunteering for many years as a reviewer for the computer science section of Mathematical Reviews, published by American Mathematical Society.

My professional life took me through the major generations of architectures and technologies, and I was fortunate to have multiple incarnations along the way: hardware engineer, software developer, microprocessor system programmer, system architect, performance analyst, project manager, scientist, etc. Each “embodiment” contributed to my vision of a computer system as an amazingly complex universe living by its own laws that have to be discovered in order to ensure that the system delivers on expectations.

When perestroika transformed the Soviet Union to Soviet Disunion, I came to work in the United States. For the past 15 years as an Oracle consultant, I was hands-on engaged in performance tuning and sizing of enterprise applications for Oracle’s customers and prospects. I executed hundreds of projects for corporations such as Dell, Citibank, Verizon, Clorox, Bank of America, AT&T, Best Buy, Aetna, Halliburton, etc. Many times I was requested to save failing performance projects in the shortest time possible, and every time the reason for the failure was a lack of understanding of the fundamental relationships among enterprise application architecture, workload generated by users, and software design by engineers who executed system sizing and tuning. I began collecting enterprise application performance problems, and over time I found that I had a sufficient assortment to write a book that could assist my colleagues with problem troubleshooting.

I want to express my gratitude to people as well as acknowledge the facts and the entities that directly or indirectly contributed to this book. My appreciation goes to:

Knowledgeable and honest Soviet engineers and scientists I was very fortunate to work with; they always remained Homo sapiens despite tremendous pressure from the system to make them Homo sovieticus.The Soviet educational system with its emphasis on mathematics and physics.The overwhelming scarcity of everything except communist demagogy in the Soviet Union; as the latter was of no use, the former was a great enabler of innovative approaches to problem solving (for example, if the computer is slow and has limited memory, the only way to meet requirements is to devise a very efficient algorithm).U.S. employers who opened for me the world of enterprise applications filled with performance puzzles.Performance engineers who drove tuning and sizing projects to failures—I learned how they did it, and I did what was necessary to prevent it; along the way I collected real-life cases.Reviewers who reconsidered their own priorities and accepted publishers’ proposals to examine raw manuscripts; the recipes they recommended made it edible.My family for the obvious and the most important reason—because of their presence, I have those to love and those to take care of.

L.G.

Preface

In this chapter: why the book was written; what it is about; its targeted audience; and the book’s organization.

WHY I WROTE THIS BOOK

Poorly performing enterprise applications are the weakest links in a corporation’s management chains, causing delays and disruptions of critical business functions. In trying to strengthen the links, companies spend dearly on applications tuning and sizing; unfortunately, the only deliverables of many of such ventures are lost investment as well as the ruined credibility of computer professionals who carry out failed projects.

In my opinion, the root of the problem is twofold. Firstly, the performance engineering discipline does not treat enterprise applications as a unified compound object that has to be tuned in its entirety; instead it targets separate components of enterprise applications (databases, software, networks, Web servers, application servers, hardware appliances, Java Virtual Machine, etc.).

Secondly, the body of knowledge for performance engineering consists of disparate and isolated tips and recipes on bottleneck troubleshooting and system sizing and is guided by intuitional and “trial and error” approaches. Not surprisingly, the professional community has categorized it as an art form—you can find a number of books that prominently place application performance trade in the category of “art form,” based on their titles.

What greatly contributes to the problem are corporations’ misguided efforts that are directed predominantly toward information technology (IT) department business optimization while typically ignoring application performance management (APM). Because performance indicators of IT departments and enterprise applications differ—hardware utilization on one side and transaction time on another—the perfect readings of the former do not equate to business user satisfaction with the latter. Moreover, IT departments do not monitor software bottlenecks that degrade transaction time; ironically, being undetected, they make IT feel better because software bottlenecks bring down hardware utilization.