Discoverer10g904capacityplanninggui 132610 PDF

Oracle Application Serer
Discoerer 10g ,9.0.4,

Capacity Planning Guide

.v Oracte !bite Paer
]avvar, 200:
OracIe AppIication Server Discoverer 10g (9.0.4) Capacity PIanning Guide Page 2
Oracle Application Serer Discoerer 10g ,9.0.4,
Oeriew............................................................................................................. 3
Introduction ....................................................................................................... 3
CAPACI1\ PLANNING GOALS............................................................... 4
Number o concurrent users....................................................................... 4
Lxpected response time............................................................................... 4
Data set size and worksheet layout ............................................................ 5
RLSOURCLS.................................................................................................... 5
Number o processors ................................................................................. 5
Memory requirements .................................................................................. 5
SIZING.............................................................................................................. 6
Methodology.................................................................................................. 6
Architecture ................................................................................................... 6
lardware and Sotware Lmployed............................................................
Coniguration or 1uning Parameters.........................................................
Deried lormula........................................................................................... 8
Sizing Lxample.............................................................................................. 8
Limitations ..................................................................................................... 8
Upgrading Versus Adding Serers ............................................................. 9
Conclusion........................................................................................................ 10
Appendix .......................................................................................................... 10
Appendix A - 1est Scenario Details........................................................ 10
Simple Scenario low ............................................................................. 11
Complex Scenario low ......................................................................... 11
Appendix B - Oracle AS 10g ,9.0.4, Coniguration Details ................ 13
Appendix C - Database Coniguration Details...................................... 13
Appendix D - Reerences ......................................................................... 14

Oracle Application Serer Discoerer 10g ,9.0.4,
OVERVIEW
1his paper demonstrates the exceptional scalability o the Oracle Application
Serer Discoerer 10g ,9.0.4, solution. Discoerer achiees near-linear scalability
with the CPU processing power and memory o the serer.
1his paper proides sizing guidelines to help consultants and system administrators
successully plan and implement their system to leerage the scalability o
Discoerer.
Serers may be added to a clustered Discoerer deployment to accommodate any
number o users. lor example, i a user population supported on 2 serers grows
by 50, an additional serer can be added to accommodate the additional user
population while maintaining the current perormance. 1his lexible approach
proides insurance in case o sudden shits in business needs - serers may be re-
tasked quickly without interrupting the aailability o Discoerer.

INTRODUCTION
Capacity planning o the middle tier or OracleAS Discoerer is based on:
the number o users concurrently accessing the system
the particular mix o Discoerer Plus and Discoerer Viewer they are
using to access their data
the size o the data set and complexity o the layout o the worksheets
being executed.
1he testing methodology used to determine the sizing ormula was to run arious
scenarios against systems that were limited in either memory or CPU capacity. 1he
scenarios were repeated with increasing numbers o users until a signiicant drop
o in response time was detected. 1he test results were then used to determine the
incremental memory and CPU required per user.
1he capacity planning ormula proided in this white paper seres only as general
guidance or your Discoerer implementation. It is strongly recommended that
you ollow the methodology explained in this white paper and conduct your own
scalability tests using your own worksheets and data to more accurately achiee the
capacity planning goals or your business.
CAPACITY PLANNING GOALS
1he goal o capacity planning or Discoerer is to determine the hardware needed
in the middle tier to support a gien number o concurrent users using a particular
mix o Discoerer Plus and Viewer and a range o data set size and worksheet
complexity while maintaining a reasonable response time to user actions.
Number of concurrent users
Concurrent users or Discoerer are those users who are actiely running queries
and analyzing data.
\hen planning your Discoerer system you irst need to get a realistic estimate o
how many users will be accessing the system at the same time. Be sure to use
realistic estimates o the number o concurrent users when using these sizing
guidelines. In most cases the number o concurrent users is a raction o the entire
user population. Lxperience with customers has shown that the number o
concurrent users is typically 10, and oten less, o the entire Discoerer
population.
Second, you need to determine how many o those users will be using Discoerer
Plus and how many will be using Discoerer Viewer. Determining whether users
should use Plus or Viewer should be based on the requirements each user has and
the unctionality proided in each interace. It is expected that users who need to
create and modiy worksheets will use Plus. Users who only need to iew and
analyze data are expected to use Viewer. loweer, you may also want to consider
resource requirements when determining how many users will use Plus and how
many will use Viewer. Discoerer Plus is a Jaa based client that proides a high
degree o interactie manipulation, query modiication, and report building. Plus
tends to consume more network bandwidth but less middle-tier resource since the
rendering and display o the user interace is on the client machine. Discoerer
Viewer is a pure l1ML client designed to iew reports and do some analysis.
Viewer tends to consume less network bandwidth and more mid-tier resources
since the rendering and display o the user interace runs on the middle tier.
Expected response time
Since Discoerer is an end user, ad-hoc query tool it is diicult to predict response
times or the initial querying o data. Query response times can be greatly impacted
by database design, the amount o data being returned, or the layout o data in the
worksheet. laing said that, with a well designed database, reasonable data set and
worksheet layout, users can expect query response times anywhere rom a second
or two to less than 10 seconds een against large data sets. Once the data is
queried, near instantaneous response time is expected as users drill and piot
through the data.
See the Oracle Database Data
Warehousing Guide for guidance on how
to design your database for Business
InteIIigence queries.
Data set size and worksheet Iayout
\ou will need to understand the relatie size o the data set that users will be
querying and the complexity o the layout in their worksheets. 1he larger the data
set and the more complex the worksheet layout, the greater the demand on middle
tier resources. Keep in mind that Discoerer is an ad-hoc data analysis tool or end
users so it is expected that users will create worksheets that display a reasonable,
humanly readable result.
It is recommended that users ollow the guidelines in chapter 10 Optimizing
OracleAS Discoerer perormance and scalability` o the Oracte .ticatiov errer
Di.corerer Covfigvratiov Cviae 10g ;.0.1). By ollowing these guidelines users
should be able to create worksheets that not only perorm well and display data in a
reasonable layout, but also put only reasonable loads on the middle tier.

RESOURCES
1he outcome o capacity planning will be a recommendation that coers the
physical resources required to meet your capacity planning goals. 1he
recommendation will be the number o processors and amount o physical memory
,RAM, needed to support the number and mix o concurrent users you expect to
hae on the system. I you are able to use \eb Cache, you may be able to reduce
the middle tier requirements or your user population. I you are able to use
summary olders or scheduled workbook results, you may be able to achiee better
response times using your Discoerer system.
Number of processors
1he sizing recommendation or number o processors is based on the class and
number o processors used in the chosen benchmark enironment.
1here is no uniersally accepted industry standard or comparing the power` o
dierent CPUs. loweer, many major endors do publish popular benchmarks,
such as SPLC CPU 2000. lor more inormation isit: http:,,www.spec.org. 1he
SPLC website proides benchmarks, results and inormation regarding the correct
use and interpretation o those results.
In the absence o data or other processors and operating systems you may make an
estimation based on no less than the total Mlz determined by this sizing guideline.
Memory requirements
1he sizing recommendation or amount o memory ,RAM, is based on the chosen
benchmark enironment.
By foIIowing the "Optimizing OracIeAS
Discoverer performance and scaIabiIity"
guideIines in the Oracle Application Server
Discoverer Configuration Guide 10g
(9.0.4), users shouId be abIe to create
worksheets that perform weII, dispIay data
in a reasonabIe Iayout, and aIso put onIy
reasonabIe Ioads on the middIe tier.

See the Oracle Application Server
Discoverer Configuration Guide 10g (9.0.4)
for detaiIs on how to use Discoverer with
Web Cache. See the Oracle Discoverer
Administrator Administration Guide (9.0.4)
for detaiIs on using summary foIders and
enabIing scheduIing. See the OracleAS
Discoverer Plus User's Guide 10g (9.0.4)
for detaiIs on scheduIing workbooks.

Like processor comparisons, there is no accepted industry standard or comparing
memory o dierent machines. In the absence o comparison data, you may make
an estimate o no less than the total RAM determined by this sizing guideline.
SIZING
MethodoIogy
1he testing methodology used to determine the sizing ormula was to run arious
scenarios against systems that were limited in either memory or CPU capacity.
1here are two scenarios - Simple and Complex - based on the complexity o the
tasks completed during the scenario. 1he Simple scenario represents a casual user
who typically iews existing reports and perorms limited additional analysis. 1he
Complex scenario simulates a more sophisticated user who perorms deeper
analysis and uses more product eatures. ,see Appendix A or details,. 1he
scenarios were repeated using Plus or Viewer with increasing numbers o
concurrent users until a signiicant drop o in response time was detected. 1he
test results are then used to determine the incremental memory and CPU required
per user.
lor example, to determine the incremental memory requirements per user o
Discoerer Plus running the Complex Scenario, a machine is physically conigured
to hae 4 CPUs but only 1 GB o memory. Conigured this way the machine has
plenty o processing power but is memory bound. 1hen, using Plus, the Complex
scenario is run seen times with a range o users starting with 10 and going up to
80. lor each run, aerage response time is recorded and memory usage is
measured. \e obsere or the runs o 10 through 60 users, the aerage response
time remains relatiely lat, only increasing ~ 1 second oer the entire range rom
10 to 60 users. loweer, aerage response time dramatically increased or the runs
with 0 and 80 users by 10 and 15 seconds respectiely. So we look at the aerage
memory consumption or the run with 60 users, when response time was still
acceptable, and obsere that incremental memory consumption per user is 10.14
MB. Additional tests are run on a machine with 4 CPUs and 2 GB memory and
these tests conirm that the actor is accurate. 1his number becomes the actor or
incremental memory needed to support each user running the Complex Scenario
using Plus and still maintain acceptable perormance.
In a similar way the CPU requirements or incremental users are determined. 1ests
are run with a range o users or all our combinations o Viewer and Plus or the
Simple and Complex scenarios.
Architecture
Architecture used in the testing is the standard architecture recommended in the
product documentation - consisting o a middle tier with one machine running
OracleAS Discoerer and another machine running OracleAS Inrastructure.
Users shouId foIIow the methodoIogy
expIained in this white paper and conduct
scaIabiIity tests with their own data and
environment to more accurateIy achieve
the capacity pIanning goaIs for their
business.

1here was one machine running Oracle Database Lnterprise Ldition and a PC
client machine simulating multiple users.
Hardware and Software EmpIoyed
Hardware
Host CPU class CPUs MHz/CPU RAM
Application Sever UltraSPARC II 2 or 4 450 1, 2, or 4 GB
Infrastructure Intel P4 1 2400 2 GB
Database UltraSPARC II 2 450 4 GB
Client Intel P4 1 100 512 MB

Software
Host Product version JVM OS
Application Sever Oracle AS 10g Discoerer ,9.0.4, 1.4.1_03 Sun OS 5.9
Infrastructure Oracle AS 10g Inrastructure ,9.0.4, 1.4.1_03 Red lat Linux AS 2.1
Database Oracle Lnterprise Ldition 9.2 N,A Sun OS 5.8
Client Mercury LoadRunner .6 JInitiator 1.3.1 \indows XP

1he network between the client, application serer, inrastructure serer, and
database serer is a last Lthernet, lull-duplex, switched 100Mbps network. All
machines are physically close to each other, within the same subnet and building.
Configuration or Tuning Parameters
1he Application Serer Discoerer machine was optimally conigured to run
Discoerer. lor example, the only OC4J process running was the
OC4J_BI_lorms instance. Application Serer Control was not running. Oracle
Application Serer and Discoerer coniguration parameters were set according to
the guidelines in chapter 10 Optimizing OracleAS Discoerer perormance and
scalability` o the Oracte .ticatiov errer Di.corerer Covfigvratiov Cviae 10g ;.0.1).
lor additional details see the appendix.
Derived FormuIa
Sizing Calculator for Sun Solaris on UltraSPARC II 4S0 MHz
User
Supplied
Incremental
Mlz actor
Incremental
Mlz req`d
Incremental
RAM actor
Incremental
RAM MB req`d
4 o Simple Plus Users * (4.1) = * (8.1) =
4 o Complex Plus Users * (8.3) = * (10.2) =
4 o Simple Viewer Users * (18.6) = * (10.1) =
4 o Complex Viewer Users * (28.1) = * (20.3) =
1otal Concurrent Users 1otal Mlz 1otal RAM
Note that an additional 260 MB RAM is required or the base Oracle Application
Serer processes - l11P Serer, OC4J, etc.
Sizing ExampIe
Lxample Sizing Calculator for Sun Solaris on UltraSPARC II 4S0 MHz
User
Supplied
Incremental
Mlz actor
Incremental
Mlz req`d
Incremental
RAM actor
Incremental
RAM MB req`d
4 o Simple Plus Users 20 * (4.1) = 82 * (8.1) = 162
4 o Complex Plus Users 10 * (8.3) = 83 * (10.2) = 102
4 o Simple Viewer Users 50 * (18.6) = 930 * (10.1) = 505
4 o Complex Viewer Users 20 * (28.1) = 562 * (20.3) = 406
1otal Concurrent Users 100 1otal Mlz 1657 1otal RAM 1175
Note that an additional 260 MB RAM is required or the base Oracle Application
Serer processes - l11P Serer, OC4J, etc.
In this example, there are 20 Simple Plus users, 10 Complex Plus users, 50 Simple
Viewer users, and 20 Complex Viewer users - a total o 100 users.
1he calculator estimates this mix o users requires 165 Mlz o UltraSPARC II
CPU processing power and 1435 MB o RAM ,115 MB or the users - 260 MB
or the base Application Serer, aboe whateer processor and memory is needed
or the OS and any other applications. 1his user population could be supported on
a Sun L420R with our 450 Mlz processors ,CEILING (1657/450), and 2 GB
RAM ,CEILING (1435/1024),.
Limitations
1he actors in this calculator are based on the speciied test scenarios that are
intended to simulate real world workloads. Results may ary with dierent
application databases, dierent hardware, and dierent workloads. In particular,
dierences in CPU architecture and speed may aect the results. \ithin the same
CPU architecture, it may be reasonable to equate CPU power to the number o
CPUs multiplied by their speed ,4 o CPUs x clock speed,. lor example, two
450Mlz UltraSPARC CPUs may proide roughly the same power as one
1050Mlz UltraSPARC CPU. loweer, power comparisons between dierent
CPU architectures may not be alid.
Gien the degree to which database design, worksheet implementation, network,
operating system, and processor architecture dierences can impact perormance
and scalability, there is no substitute or running your own scalability tests in your
enironment.
laing said that, these sizing guidelines can be used as a starting point or planning
your hardware needs or your Discoerer enironment. 1o create a more
conseratie estimate you could weight your user population to include more
Complex Viewer users than actually anticipated. 1o create a more aggressie
estimate, you could weight your population to include more the Simple Plus users
than actually anticipated.
In either case you can depend on the near linear scalability o Discoerer and add
more low cost serers as your needs grow.
Upgrading Versus Adding Servers
1hese tests show that OracleAS Discoerer ,9.0.4, is primarily CPU-bound. I a
serer`s perormance dramatically decreases or cannot support additional users,
CPU resources should be checked irst, memory resources second, and the
database perormance last.
1. Monitor the CPU usage, ree memory aailable, disk space aailable, and disk
I,O o the serer.
2. I CPU usage appears high ,almost always aboe 90, while memory and disk
are not heaily used, then add CPUs by upgrading the serer or adding another
serer. Use the calculators to determine the hardware required or the additional
serer,s,.
3. Otherwise, i CPU usage appears moderate and memory usage and disk I,O
appear ery high, the serer has insuicient memory ,real and irtual,. Virtual
memory operations also account or some o the CPU usage. Add more real
memory to the system and continue to obsere the system.
4. loweer, i CPU usage, memory usage, and disk I,O all appear high, the serer
is completely undersized. Use the calculators or a sanity check on the serer
coniguration and plan to either upgrade the serer or add additional serers.
5. I none o the serer`s resources appear to be the limiting actor, monitor the
database serer,s, that users are querying. Discoerer must retriee data rom the
database to respond to query requests - the application serer may be waiting or
data while the database serer is saturated by query actiity.
CONCLUSION
1he results rom the benchmark tests show that Oracle Application Serer
Discoerer 10g is a robust BI platorm with near-linear scalability.
1his white paper presents the methodology or conducting capacity tests and an
illustratie capacity planning calculator or OracleAS Discoerer 10g. Since the
benchmark systems and test scenarios may not relect your enironment, you
should ollow the methodology and conduct your own capacity planning tests with
your systems and data to derie the most accurate resource requirements or your
business needs. \ou can use the calculator to derie a preliminary capacity
planning estimate or your implementation.
Because o its proen scalability, customers know with conidence that Oracle
Application Serer Discoerer 10g will meet their uture demands, and business
decisions concerning uture growth - such as purchasing hardware or upgrading
existing systems - can be made saely.
APPENDIX
Appendix A - Test Scenario DetaiIs
1he test scenarios were recorded using an industry standard load-testing tool to
simulate a multi-user enironment. 1he scenarios are recorded in the exact
sequence o steps deined in the scenario lows below. A randomized think time o
45-5 seconds is proided between arious steps in the workload. 1hink time
randomizes the tasks being perormed at a snapshot in time to simulate real world
usage. 1hink time is not included in the transaction response time results.
Users are launched simultaneously in groups. Lach group consists o up to 25
users. \ithin a group, 5 users are initialized eery 30 seconds ,this consists o login
and opening a deault worksheet,. Simultaneous login and opening o a workbook
by all users does not represent a real world enironment, thus, or the irst iteration
through the scenario, users in a group do not start running tasks until all the users
in that group are initialized. 1his ensures that login and opening the workbook,
which are part o the test initialization, do not simultaneously impact perormance.
Login and the opening o a workbook are included in the results o all subsequent
iterations though. Ater initialization, one user begins the ull test scenario eery 30
seconds.
Once all users inish executing the scenario, the transaction response times
reported by the tool or the steady state are analyzed. 1he steady state is deined as
the time during which all the users are running through the scenario - no users are
Refer to the OracIe Database
documentation Iibrary for a detaiIed
description of how to monitor database
performance.

still initializing and no users hae inished the scenario. lence, maximum usage o
resources will only be seen during the steady state.
1he business area used or the test scenarios is the Video Stores 1utorial. It is
based on a small star schema with 8,489 rows in the act table with 5 acts. 1here
are three dimension tables with 20, 141, and 912 unique alues.
1wo scenarios were used or the scalability tests, based on the complexity o the
tasks done during the scenario.
SimpIe Scenario fIow
1he simple scenario consists o tasks perormed on a workbook with two
worksheets:
1able - table worksheet with 125 rows display, aggregated rom 358 rows
o data in the database.
Crosstab - crosstab worksheet with 1 page item ,6 alues,, 2 items on the
top axis ,12 alues,, and 3 items on the side axis ,20 alues,. 240 cells
displayed, aggregated rom 1,181 rows o data in the database.
1he ollowing low o tasks are perormed in this scenario:
o Connect
o Open workbook ,executes 1able sheet by deault,
o Page through results o the table ,5 times,
o Change page axis item
o Switch to Crosstab sheet
o Piot an item
o Change page axis item
o Drill once
o Disconnect
1he scenario uses a think time o 45-5 seconds between each task. 1his scenario
represents a casual user who typically iews existing reports and perorms limited
additional analysis. 1he worksheets inoled do not return large amounts o data.
1his is appropriate as the casual user iews reports that should already be ocused
and reined or requent use. 1his scenario represents the simplest` set o tasks
that a real user perorms.
CompIex Scenario fIow
1he complex scenario consists o tasks perormed on a workbook with our
worksheets:
Big Crosstab - crosstab worksheet with 2 page items ,4 and 3 alues each,,
2 items on the top axis ,10 alues,, and 5 items on the side axis ,280
alues,. 2800 cells displayed, aggregated rom 4200 database rows.
Ag Crosstab - crosstab worksheet with 1 page item ,3 alues,, 2 items on
the top axis ,12 alues,, and 4 items on the side axis ,18 alues,. 216 cells
displayed, aggregated rom 211 database rows. Some cells show no alue.
Big 1able - 100 rows displayed per page 153 rows total, 153 rows rom
the database ,no aggregation,
Small 1able - 53 rows displayed based on 53 rows rom the database ,no
aggregation,
1he ollowing low o tasks are perormed in this scenario:
o Connect
o Open workbook ,executes Big Crosstab by deault, returns 1050
rows,
o Drill on the side axis rom Product Category to Product
Description or all alues ,now 4200 rows total,
o Drill on the top axis rom Calendar Quarter to Calendar Month
or all alues ,now 12,436 rows total,
o Change the page axis item
o Switch to Ag Crosstab
o Lxport to Lxcel
o Display graph below data ,a graph already exists but it-s display
option is set to hidden`,
o Piot Data Points to the page axis
o Change the page axis items
o Switch to Big 1able
o Skip to page 2 o the results
o Skip to the last page o the results ,at 25 rows per page, 63 should
be the last page,
o Go to Small 1able
o Print the worksheet with both the table and the graph
o Disconnect
1he scenario uses a random think time o 45-5 seconds between each task. 1his
scenario simulates a more sophisticated user who perorms deeper analysis and uses
more product eatures.
Appendix B - OracIe AS 10g (9.0.4) Configuration DetaiIs
1he Application Serer Discoerer machine was optimally conigured to run
Discoerer.
1he Oracle l11P serer httpd.con was conigured as ollows:
KeepAlie O
MaxClients 400
J2LL,Oracle Containers or Jaa was conigured as ollows:
OC4J_BI_lorms was the only OC4J process running
OC4J_BI_lorms instance Serer settings o one VM process per CPU
,note that the increase in perormance o haing one VM process per CPU
oer one VM process per 2 CPUs is marginal so that i memory usage is a
concern, 1 VM process per 2 CPUs might be better or real world
applications,
Jaa command line conigured with 512 MB heap:
-Xmx512M
Jaa command line conigured mod_oc4j timeout set to 1 minute:
-Doracle.j2ee.http.socket.timeout~60000
\ebCache process was disabled.
See the appropriate Oracle Application Serer documentation or details on
coniguring your Oracle Application Serer.
Discoerer Query Prediction was disabled. See chapter 20 "Discoerer registry
settings" in the Oracte Di.corerer .avivi.trator .avivi.tratiov Cviae 10g ;.0.1) or
details on how to disable Query Prediction.
Appendix C - Database Configuration DetaiIs

1he ollowing parameters were set or the Database.
db_block_size 8192
open_cursors 400
db_block_buffers 24000
shared_pool_size 104857600
large_pool_size 614400
java_pool_size 20971520
log_checkpoint_interval 100000
log_checkpoint_timeout 18000
log_buffer 1638400
query_rewrite_integrity STALE_TOLERATED
_query_rewrite_vop_cleanup TRUE
job_queue_processes 2
job_queue_interval 60
timed_statistics true
sort_area_size 1310720
sort_multiblock_read_count 16
sort_area_retained_size 0
optimizer_mode all_rows
query_rewrite_enabled true
processes 400
Appendix D - References
Oracte .ticatiov errer Di.corerer Covfigvratiov Cviae 10g ;.0.1)
Oracte Di.corerer .avivi.trator .avivi.tratiov Cviae 10g ;.0.1)
Oracte .ticatiov errer Di.corerer Ptv. |.er`. Cviae 10g ;.0.1)
Oracte Databa.e Data !arebov.ivg Cviae
Oracte .ticatiov errer .avivi.trator`. Cviae 10g ;.0.1)
Oracte .ticatiov errer Perforvavce Cviae 10g ;.0.1)
Oracte .ticatiov errer !eb Cacbe .avivi.trator`. Cviae 10g ;.0.1)

Capacity PIanning White Paper
January 2005
Author: Mike Donohue

OracIe Corporation
WorId Headquarters
500 OracIe Parkway
Redwood Shores, CA 94065
U.S.A.

WorIdwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracIe.com

OracIe Corporation provides the software
that powers the internet.

OracIe is a registered trademark of OracIe Corporation. Various
product and service names referenced herein may be trademarks
of OracIe Corporation. AII other product and service names
mentioned may be trademarks of their respective owners.

Copyright 2005 OracIe Corporation
AII rights reserved.

Discoverer10g904capacityplanninggui 132610 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Discoverer10g904capacityplanninggui 132610 PDF

Uploaded by

Copyright:

Available Formats

Oracle Application Serer

Discoerer 10g ,9.0.4,

You might also like