DONE-08 Sizing and Performance Tuning N-Tier Applications Mike Furgal Performance Manager Progress...

DONE-08Sizing and Performance Tuning N-Tier Applications

Mike FurgalPerformance ManagerProgress [email protected]

2 DONE-08 Sizing and Performance Tuning N-Tier Applications © 2005 Progress Software Corporation

D I S C L A I M E R

Under Development

This talk includes information about potential future products and/or product enhancements.

What I am going to say reflects our current thinking, but the information contained herein is preliminary and subject to change. Any future products we ultimately deliver may be materially different from what is described here.

D I S C L A I M E R


Agenda

Overview of AppServer™ Configurations Benchmark Methodology AppServer Internals Benchmark Results Conclusions


AppServer™ Benefits

Partitions presentation logic from Business Logic

Ease of deployment of Business Logic Business Logic is closer to the Data for

complex operations Security

– File Permissions

– Running Environment


Agenda

Overview of AppServer Configurations Benchmark Methodology AppServer Internals Benchmark Results Conclusions


Overview of AppServer Configurations

Machine Configurations AppServer Configurations NameServer


Machine Configurations

2 Server Machines (1-DB and 1-AppServer)– HP Itanium (rx4640)

4 CPUs 8 GB Memory Storage Area Network (SAN)

2 Client Machines– Used to drive the workload


AppServer Configurations

Stateless AppServer– Uses the least amount of resources

– Supports the largest amount of users AppServer and Database on the same

machine (Shared Memory Connection) AppServer on a dedicated machine


NameServer

Used to manage multiple AppServers Ran test suite both with the NameServer

and without the NameServer– Had no effect on performance since it’s

just involved when making a connection.


Agenda



Benchmarking Methodology

Scale OLTP Users– No think time– Each benchmark user 20 OLTP users

Measure response time– Stop when response time is longer than 2

seconds. Make changes to the AppServer

configuration only– Database is assumed to be tuned!


Database Tuning

Before Image and Data extends spread across multiple disks

Appropriate -spin settings– 200,000 spin tries

Appropriate –B setting– Tested with the data set cached in memory

– Tested with ½ of the data set cached in memory Appropriate Before Image cluster-size setting

– Checkpoint every 2 minutes


Benchmarking Methodology

Step 1: Run a test case Step 2: Measure the performance Step 3: Analyze the results Step 4: Change 1 thing Step 5: Go to Step 1

Iterate on this process


Workloads Tested

Multiple workloads tested Database Workload

– 100 reads, 3 updates, 1 create Business Logic Workload

– 200 DB Reads– 200 Temp Table Creates and Updates– 3 Database Updates– 1 Database Create

No other activity on the machines


Things to remember

Kernel Tuning– Decrease the OS Buffer Cache (dbc_max_pct)– Increase number of threads/process (nkthread)– Increase max open files/process (maxfiles)

Monitor AppServer Broker Memory Usage– Memory used for size of messages. Application

specific– Each Agent adds 4 MB – Each connected client adds 100K

AppServer Agents memory usage– Similar to character clients memory usage


NUMA Considerations

Memory

BUS

CP

U

CP

U

CP

U

CP

U

Memory

BUS

CP

U

CP

U

CP

U

CP

U

Node 1 Node 2High Speed

Interconnect

Non Uniform Memory Access Memory is split across nodes Ideal to have all Self Service Processes on the same node

as the Database Buffer Pool– Possible future enhancement for OpenEdge


Agenda



AppServer Processes

o

o

o

o

o

o

Client 1

Client 3

Client n

Client 1

Thread

Client 1

Thread

Client 1

Thread

Client 2

Thread

Client 1

Thread

Client 3

Thread

Client 1

Thread

Client n

Thread

Client 2

AS Agent

1

AS Agent

2

AS Agent

3

o

o

o

AS Agent

n

AS 1

Thread

AS 2

Thread

AS 3

Thread

o

o

o

AS 4

Thread

Request 1

Request 2

Request 3

Request 4

o

o

o

Request n

Request QueueListener

Thread


AppServer Request Queue

o

o

o

o

o

o

Client 1

Client 3

Client n

Client 1

Thread

Client 1

Thread

Client 1

Thread

Client 2

Thread

Client 1

Thread

Client 3

Thread

Client 1

Thread

Client n

Thread

Client 2

AS Agent

1

AS Agent

2

AS 1

Thread

AS 2

Thread

Request 1

Busy

Request 2

Busy

Request 3

Waiting

Request 4

Waiting

Request 5

Waiting

Request QueueListener

Thread


AppServer Properties

initialSrvrInstance – Number of initial AS Agents

srvrStartupTimeout– Time to wait for a free server before starting

a new one [default is 3 seconds] maxSrvrInstance

– Total number of AS Agents maxClientInstance

– Max number of clients that can connect

$DLC/properties/ubroker.properties [.README]


AppServer Properties

autoTrimTimeout – Time to wait before stopping idle AS Agent

[default 15 minutes] minSrvrInstance

– Lowest Number of AS Agents requestTimeout

– Time a client waits for an Agent. If expired the client is disconnected

$DLC/properties/ubroker.properties [.README]


Agenda



AppServer Agent “Think Time”

Response Time <= 2 Seconds1 Second "Think Time"

0

5

10

15

20

25

0 2 4 6 8 10 12

AppServer Agents

Us

ers

Clients

AppServer Workload causes a Pause


Database Workload

Database Workload – 100 reads, 3 updates, 1 create

# of users where response time < 2 seconds.Cached Database

0100020003000400050006000

0 2 4 6 8 10 12 14 16

AppServers

Use

rs


Database Workload

Database Workload – 100 reads, 3 updates, 1 create

# of users with response time < 2 seconds95% Buffer Hits

0100020003000400050006000

0 2 4 6 8 10 12 14 16

AppServer Agents

Use

rs


Business Logic Workload

Business Logic – 100 DB Reads, 200 TT Creates/Updates

# of users where response time if < 2 seconds100% Buffer Hits

0500

10001500200025003000

0 2 4 6 8 10 12 14 16

AppServer Agents

Use

rs


Business Logic Workload

Business Logic – 100 DB Reads, 200 TT Creates/Updates

# of users where response time < 2 seconds.95% Buffer Hits

0

1000

2000

3000

4000

0 2 4 6 8 10 12 14 16

AppServers

Use

rs


Agenda



Conclusions

Keeping the business logic near the data provides the best performance

A small number of Agents can handle many users– CPU bound workloads achieve best performance with 1

AppServer Agent per CPU– I/O Bound workloads require more AppServer Agents– If Agents are busy serving large requests then adding

more Agents helps (can be managed dynamically).– May need to segment AppServers Agents for different

uses (OLTP vs. Reporting) Your Mileage May Vary


Odds and Ends

Constantly looking for places to make performance improvements– 64bit performance improvements

Removed the performance penalty for compatibility

Typically 35% penalty 64bit r-code is now different than 32bit r-

code in OpenEdge™ 10.1A


Questions?


Thank you for your time!

DONE-08 Sizing and Performance Tuning N-Tier Applications Mike Furgal Performance Manager Progress...

Documents

Transcript of DONE-08 Sizing and Performance Tuning N-Tier Applications Mike Furgal Performance Manager Progress...