<Insert Picture Here>

Methodology of enterprise applications capacity

planning by real life examples

Leonid Grinshpan, Ph.D.

Consulting Technical Director, Oracle Corporation

Share to Facebook

Share to LinkedIn

Share toTwitter

Share to SlideShare

The views expressed in this

presentation are author’s own and

do not reflect the views of the

companies he had worked for neither

Oracle Corporation.

All brands and trademarks mentioned

are the property of their owners.

The presentation is based on

2

The presentation is based on

author’s book

“Solving Enterprise Applications

Performance Puzzles: Queuing

Models to the Rescue”

(available in bookstores and from Web

booksellers from March 2012)

http://www.amazon.com/Solving-

Enterprise-Applications-Performance-

Puzzles/dp/1118061578/ref=sr_1_1?ie=

UTF8&qid=1326134402&sr=8-1

Presentation’s goal

Learning by examples is the fastest way to master enterprise

applications capacity planning methodology

This presentation contains real life examples of enterprise applications

capacity planning methodology described in details in author’s book:

“Solving Enterprise Applications Performance Puzzles:

3

“Solving Enterprise Applications Performance Puzzles:

Queuing Models to the Rescue”

(available in bookstores and from Web booksellers from March 2012)

http://www.amazon.com/Solving-Enterprise-Applications-Performance-

Puzzles/dp/1118061578/ref=sr_1_1?ie=UTF8&qid=1326134402&sr=8-1

Input data for capacity planning

1. Workload characterization

� List of business transactions

� Number of users per each business transaction

� Per each transaction an anticipated number of transactions per user

per hour (transaction rate).

� Per each transaction its response time expected by the application

users.

4

Example of workload characterization

Input data for capacity planning

2. Hosting platform

� Hardware architecture (connections

among servers and numbers

of servers on each tier)

5

Example of hardware architecture

� Distribution of application’s software components among servers

(software components hosted by each server)

� Specification of each server (number of cores and CPUs, clock

speed, RAM size etc)

� Operating system (Windows, LINUX, etc)

Input data for capacity planning

3. Transactions profiles

� Profile of each business transaction

Transaction profile is comprised of the time intervals a transaction has spent in

system servers it has visited when application was serving only single request

Example of transactions profiles

6

Input data for capacity planning

4. What-if scenarios

Each modeling estimate is generated for a specified set of input data that includes:

– Workload.

– Profile of each transaction.

– Hardware architecture, specification of servers (number of servers, number of

CPUs on each server, server types).

– Distribution (hosting) of application’s components among servers.

7

Changing any of the above represents new what-if scenario.

Mapping system into model

System

8

System’s model

Solving model

�Author usesTeamQuest software to solve models http://teamquest.com/

� It is possible to solve models using open source software packages. One

of them is Java Modeling Tools (JMT); it is developed by Politecnico di

Milano and can be downloaded from http://jmt.sourceforge.net/. A few

following slides demonstrate its basic functionality.

9

Solving model using opens source package

Workload definition

10

Solving model using opens source package

Specification of hardware servers

11

Solving model using opens source package

Specification of transaction profiles

12

Solving model using opens source package

Modeling results (utilization of servers and transaction times)

13

Model deliverables

DELIVERABLES

� Average transaction response time for each transaction

� Utilization of each hardware server

Transaction time (seconds) Utilization of system servers (%)

14

Common what-if scenarios

1. Changing hardware platform

2. Analysis of different operating systems

3. Workload variations

4. Assessment of impact of network and remote users

5. Changing number of cores and CPUs

15

5. Changing number of cores and CPUs

6. Server farms

7. Redistribution of application’s software components

Case study 1. Customer: Financial institution. Application: Financial reporting

Workload characterization

16

Case study 1. Customer: Financial institution. Application: Financial reporting

Hosting platform

17

Case study 1. Customer: Financial institution. Application: Financial reporting

Transactions profiles

18

Case study 1. Customer: Financial institution. Application: Financial reporting

What-if scenarios

19

Case study 1. Customer: Financial institution. Application: Financial reporting

Project recommendations

20

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

Workload characterizationCustomer requested to provide capacity estimates for nine workloads

21

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

Hosting platform

22

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

Transactions profiles

23

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

What-if scenarios

Customer requested to provide capacity estimates for five hardware platforms and nine workloads

24

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

Analysis of modeling results

30 what-if scenarios evaluated, this is an example of one scenario modeling estimates and conclusions

25

Case study 2. Customer: Pharmaceutical corporation. Applications: Corporate

Planning and Budgeting, Financial reporting

Project recommendations

Recommended hardware specifications for different workloads

26

Example 1. Customer: Major credit card company. Applications: Financial

consolidation, Financial reporting

Workload characterizationWorkload is generated by the users located on different continents

27

Example 2. Customer: Major credit card company. Applications: Financial

consolidation, Financial reporting

Analysis of modeling resultsComparison of transaction times for two hardware platforms

28

Example 3. Customer: Major credit card company. Applications: Financial

consolidation, Financial reporting

Analysis of modeling resultsComparison of server utilizations for four hardware platforms

29

Example 4. Customer: Medical equipment manufacturer. Applications: Financial

consolidation, Planning, Financial reporting

Analysis of modeling resultsIdentification of “hokey stick” effect

30

For short transactions system exhibits classical hockey stick effect

because transaction time starts growing exponentially after number of users exceeds 200 (

polynomial black line on chart)

Contact author

Want to know more about

enterprise applications capacity planning?

Contact Leonid Grinshpan at 101capacityplanning@gmail.com

Share this presentation

31

Share to Facebook

Share to LinkedIn

Share toTwitter

Share to SlideShare