1 of 28

Why is the application running so slowly?[UGF2778]

Dr. Paul Dorsey & Michael RosenblumDulcian, Inc.

www.dulcian.com

2 of 28

Who Am I? – “Dr.Paul” Been Around FOREVER

Spoke at almost every big Oracle conference since ’93 First inductee to SELECT Hall of Fame

Wrote lots of books Designer, Developer, JDeveloper, PL/SQL

Won lots of awards One of initial 6 ACE Directors [+First one fired!]

Built lots of big systems Air Force Recruiting Ethiopian Ministry of Finance and Economic Development Budget System

Known for: Thick Database approach Business Rules

3 of 28

Who Am I? – “Misha”Oracle ACECo-author of 3 books

PL/SQL for Dummies Expert PL/SQL Practices Oracle PL/SQL Performance Tuning Tips & Techniques

(Rosenblum & Dorsey, Oracle Press, July 2014)Won ODTUG 2009 Speaker of the YearKnown for:

SQL and PL/SQL tuning Complex functionality

Code generators Repository-based development

4 of 28

OverviewPerformance issues are the bane of our existence. We are quick to blame the database (if we are application

developers) Even quicker to blame the developers (if we are DBAs) If all else fails, we can blame the network.

5 of 28

Presentation Goals

1. Provide a coherent methodology to identify performance issues.

2. Lay out the most common sources of those problems. 3. Discuss the most common techniques to solve these

performance problems.

6 of 28

The Problem

Too many moving piecesContemporary IT = lots of entities within the same organization.

No overall architectural approachPerformance tuning is usually initiated by end-user complaintsSystem audit = blaming contest

Aggregated statistics are meaningless … unless you can explain why a button click on the screen takes

so much time.

7 of 28

Why Performance Tuning Fails

Are we solving the wrong problem?Tuning:

Usually makes the database run better Focuses on poorly running SQL

Web applications are frequently unaffected by these performance improvement approaches.

Need to examine the entire system, not just the database.

8 of 28

Identifying Performance IssuesNeed to look at the following parts of the system

ClientApplication ServerDatabaseCommunication between client/application server/ database

9 of 28

Common Causes of Performance Problems

The most common causes of slow systems:Excessive roundtrips from the application server to the

databaseLarge pages sent to the client Performing operations in the application server that should be

done in the database Poorly written SQL and PL/SQL routines

10 of 28

Web Application Architecture

3. App Server

2. Send data from client

to app server 5. DB

6. Return Data fromDB to app server

1. Client

4. Send data fromapp server to DB

7. Data inApp Server

8. Return data from app server

to client 9. Data in client

11 of 28

Measuring Performance

Possible approaches:Direct measurement of each step

… if you can Indirect measurement using round trips

… where direct measurement is impossibleMonitor database resources

At least we know how to do that!

12 of 28

Timing Language ElementsCommand: Atomic part of the process (any command on any tier)Step: Complete processing cycle in one direction (always one-

way) Can either be a communication step between one tier and another, or a

set of steps within the same tier. Step consists of a number of commands.

Request: Action consisting of a number of steps. A request is passed between different processing tiers.

Round-trip: Complete cycle from the moment the request leaves the tier to the point when it comes back with some response information.

13 of 28

Unlikely source of problems. Should not be dismissed entirely. Using AJAX architectures, it is possible to place so much code in the

client that a significant amount of time is required before the request is transmitted to the application server.

Beware of underpowered client machines with inadequate memory and slow processors.

Steps 1 & 9 - Client

1.Client

9. Data in client

14 of 28

Step 2 - Client to Application Server

Less common cause of performance problemsTransmitting large amounts of information over the Internet may

cause problems. Uploading large files Transmitting a large block of data

2. Send data from client to app server

15 of 28

Steps 3 & 7 App Server Processing

Processing can be resource-intensive. Java programmers minimize database application logic in the middle tier. Complex data manipulation can be handled much more efficiently with

database code. Thick database approach is the key to efficiently performing web applications.

7. Data in app server

3. App server

16 of 28

Step 4 - Application Server to DB

Not instantaneous (but really fast) High number of transmission requests is #1 cause of performance problems. Database-independence is not a good idea.

Single request from a client may require many requests from the application server to the database in order to fulfill.

Examine and measure the number of round-trips from application server to database.

4. Send data from app server to DB

17 of 28

Step 5 – DB Performance Problems

Use traditional tuning. Beware of stateless implementation.

Information pertaining to a particular session must be retrieved at the beginning of every request and persistently stored at the end of every request.

Single table may generate massive I/O Redo logs Block contention

5.DB

18 of 28

Step 6 – DB to Application Server Transmission Problems

Rare problemBeware of unnecessary data movement.

One record is needed and the whole table is sent.

6. Return data from DB to app

server

19 of 28

Step 8 - App Server to Client Transmission Problems

#2 cause of performance problems Keep pages small.

Not too many fields Not too much AJAX or JavaScript Not too big a tree Not too much data in a scrolling block No images, or other unnecessary information

Measure size of page.

8. Return data from app server to client

20 of 28

Common Reasons for Poor Performance

Excessive round trips between application server and database

Moving too much into the clientSlow client-side codeSlow queriesBadly written PL/SQLImproperly tuned database

21 of 28

Measuring Performance

22 of 28

Locating Slow Performance Causes

Embed timers into a system to detect where in the nine possible steps the application performance is degrading.

Strategically placed timers will indicate how much time is spent at any one of the steps in the total process.

23 of 28

System Tuning for 3-tier Application(with numbers!)

9-step or

5 round-trip

structure

80 sec100 sec

75 sec50 sec40 sec

40 sec

4 sec

6 sec

15 sec

10 sec

2 sec

3 sec

5 sec

15 sec

ClientApp

server DATABASE

ClientApp

server DATABASE

24 of 28

Actions in 5 Round-Trip Structure

Client Level 1. From request

initiation to end of processing User clicks button Response is displayed

2. From request to application server to response receipt Start of servlet call End of servlet call

Application Level 3. From request

acceptance to moment it is sent back Start of processing in

servlet End of processing in

servlet 4. From request sent to

database Start of JDBC call End of JDBC call

Database Level 5. From request

acceptance to sending back the response Start block End of block

25 of 28

Performance-Improving Techniques

Reducing round trips to the databaseNo SQL in the application serverReduce size of client pagesTune the databaseTune the SQL

26 of 28

ConclusionsIn order to determine why an application is running

slowly, you must: Identify the reasons for the slow running code.Learn how to instrument the code to identify performance

bottlenecks in the client, application server and database.Use techniques for reducing performance problems.

27 of 28

Contact Information Paul Dorsey – paul_dorsey@dulcian.com Michael Rosenblum – mrosenblum@dulcian.com Website – www.dulcian.com Latest books:

Oracle PL/SQL Performance Tuning Tips & Techniques, McGraw-Hill Oracle PL/SQL for Dummies

28 of 28

Save the DateCOLLABORATE 17 registration will open on Thursday, October 27.

Call for SpeakersSubmit your session presentation! The Call for Speakers is open until Friday,

October 7

collaborate.ioug.org