Load Test Approach

mountainromeInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

86 εμφανίσεις

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
1

of
9

Last
Updated
-

11/1/13


Load

Test Approach



I. Introduction



The purpose of this document is an attempt to formally identify and communicate a
number of critical items for the upcoming Phase II Load Test.
These include:




Documentation of key milestones and dates for the Load Test.



Identify and document primary goals for the Load Test.



Identify and document secondary goals for the Load Test.



Identify deliverables upon completion of the Load Test.




II.
Test

Approach


A.
Key Milestones and Project Dates


The following are some key milestone dates as documented in the Load Test
P
roject
P
lan.


Milestone Description

Date Due

Completed?

Preparation for Application Server Preliminary Test
Executions

8/27



A灰pication Server Preliminary Test Exec畴ions Com灬ete

/11



Pre灡ration/Set異 景r Native A畴hentication Preliminary
Test Execs

8/28



Native A畴hentication Preliminary Test Exec畴ion
Com灬ete

/3



Pre灡ration/Set異 景r Cosign A畴hentication
Preliminary
Test Execs

/10



Cosign A畴hentication Preliminary Test Exec畴ion
Com灬ete

/17



Load Balancers Installed, Con晩g畲ud, 剥ady 景r Load Test
Exec畴ion

10/1



Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
2

of
9

Last
Updated
-

11/1/13


New Database Server (kingbird
-
II) Onsite and Machine
Room Environmentals Complete

9
/23



Basic Machine Installation Complete (AIX, Security, Oracle)

10/2


Database Server (kingbird
-
II) Ready and Available for Load
Test (DB created, authentication installed, process
scheduler started, report manager and distribution agent
started, data
validation in DB)

10/13


Application Server Configured and Ready for Load Test
Executions

9/23



Webserver Basic Installations Complete

9/23



WebLogic SNMP Monitors Ready for Load Test Executions

9/24


AIX Monitors Ready for Load Test Executions

10/13


Tuxedo Monitors Ready for Load Test Executions

8/28



All Transactions Scripted and Unit Tested against
HEWork1

10/2


All Load Test Scenarios Created, Unit Tested and Ready for
Load Test Executions

10/13


Load Test Executions


Completed Daily

10/13
-
31




B.

Primary Goals


It is critically important for the load test team to have clear, concise, attainable goals for
execution. As such, we have identified the following primary goals to achieve during
the execution of the l
o
ad test.
The primary go
als listed here will be worked on before effort is
put forth to achieve the secondary goals listed later in the document.

They are listed in order
of importance (and subsequently, execution).


Goal #1: We must create baselines of every transaction runnin
g at both 1 concurrent
user as well as the peak number of concurrent users expected in production. We must
also document the cost of each transaction on all infrastructure components.


The load testing team will execute each identif
i
ed transaction using t
he finalized load
test architecture. Each transaction will be placed in its own load test scenario
and
will be
executed twice. The first execution will include only 1 concurrent user, run sequentially
over a 5 minute period. The second execution will in
clude the full complement of
concurrent users as identified by the CPUs over a 5
-
minute period. Complete
measurements for each will be captured and documented. We will determine the cost
for each execution in terms of memory and CPU utilization on all se
rvers in the
PeopleSoft architecture as well as average transaction response time. This activity will
be limited to 1 day.

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
3

of
9

Last
Updated
-

11/1/13


Goal #2: Regardless of the load placed on the system, we must ensure that the
Tuxedo Application Server(s) do not crash during the
Load Test executions.


We recognize that it is critical that the Tuxedo Application Server not crash during
executions. As such, we will make every reasonable effort to ensure this does not
happen. Some possible actions we may take include: making adjustments to
Application S
erver configurations, making adjustments to other infrastructure
configurations to alleviate issues, implement additional Application Server domains,
and i
mplement contingencies to procure additional hardware as a last resort.
Application Server preliminary testing has been conducted and results have been
documented. A base Application Server configuration has been determined. AIG staff
are attending App
lication Server tuning training
XX/XX/XX

and a PeopleSoft
Application Server senior consultant will be onsite
XX/XX/XX
.


Goal #3: We must ensure that Cosign Authentication continues to work, and that no
failures occur due to infrastructure or authenticati
on filter issues during the Load Test
executions.


We recognize that the Cosign Authentication must not fail throughout the load test
execution phase. As such, we will make every reasonable effort to ensure this does not
happen. Some possible actions inc
lude: troubleshooting and identifying the cause of
slowdowns or failures, possible recoding of the Cosign Authentication filter to improve
performance.


Goal #4: We must ensure that we can achieve the targeted transaction throughput
ratio for the Drop/Ad
d period in any given 15
-
minute timeframe.


We recognize that Enrollment Request, BackPack and Class Search are critical
transactions and that we must meet or exceed certain performance thresholds if we are
to be successful. A basic goal of this load test

is to determine that we can sustain 1,100
enrollment over any given 15
-
minute timeframe. This transaction load was determined
through existing HEProd registration records.


Goal #5: We must ensure we can execute 100 or more Elapsed Time transactions in
any given 15
-
minute timeframe.


We recognize that Elapsed Time is another critical transaction and that we must meet or
exceed certain performance thresholds if we are to be successful. Another basic goal of
this load test is to determine that we can succ
essfully execute 100 or more transactions
over any given 15
-
minute timeframe.

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
4

of
9

Last
Updated
-

11/1/13


Goal #6: We want to ensure we can run all transactions together and still meet all
individual transaction goals for any given 15
-
minute timeframe.


We recognize that performance

of all transactions is very important. If all other goals
are met, we will strive to ensure all transactions can be executed within their given
constraints.


Goal #7: We will conduct extended load tests for a scenario of all transactions
together while
still meeting all individual transaction goals for any given 15
-
minute
timeframe.


We will conduct extended length load tests (hours) running a combination of all
transactions. Doing so will ensure that we will not encounter infrastructure or
performance
issues after hours of running at peak loads. Examples of this include
memory leaks in application server code.


The Load Test team has identified the following secondary goals to achieve during the
execution of the load test.
These goals will be worked o
n only after all primary goals have been
achieved.

They are listed in order of importance.



C.

Secondary Goals



Goal #1: We must ensure that we can run all transactions together with a reasonable
background load of poor performing panel searches and
PeopleSoft queries running
concurrently and still meet all individual transaction goals for any give 15
-
minute
timeframe.


Upon successful completion of primary goal

#7, we will turn our attention to adding a
background of poor performing panel searches an
d PeopleSoft queries to this combined
overall transaction mix. The precise load of queries and searches will be determined by
TIO DBA’s and will be based on what is seen in HEPROD today.


Goal #2: We want to ensure that the Cosign Authentication does not

fail, regardless
of load.


We recognize that Cosign must not fail, regardless of load. Cosign must be scaleable
enough to handle any potential load placed on it throughout the load test and beyond.
Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
5

of
9

Last
Updated
-

11/1/13


To ensure this is the case, we will execute at least on
e load test where the authentication
filter code is executed a minimum of 500 times concurrently.


III. Status and Reporting Metrics


A.
Complete Documentation for Every Load Test Execution
Cycle


For every Load Test execution cycle, at a minimum we will

capture and document the
following:



Complete detailed description of Load Test scenario being executed.



The IDs being used for each transaction included in the execution cycle.



The start and end times/dates for each execution cycle.



Complete LoadRunner ex
ecution statistics including:

o

Pacing of all transactions (how many transactions are released per
second.)

o

Minimum, maximum and average response times for each transaction in
the scenario as well as a complete description of each response time
reported and what it includes (login, navigation, logout, think times
etc…)

o

The success/failure rate of each transactio
n in the scenario.

o

If failures are encountered, what errors were recevied and analysis of
what they can be attributed to.

o

Hits per second.


o

Total transactions per second.



Complete Application Server statistics including:

o

Application Server service utilizat
ion.

o

Application Server concurrently connected sessions.

o

Application Server service queuing.

o

Failures of application server processes.

o

Application Server service recycle counts.

o

Additional statistics not captured in an automated fashion.



Complete Webserver

statistics including:

o

Sockets used and any issues encountered with them.

o

Number of hits, POST processes, GET processes throughout execution.

o

Java “garbage collection” frequency and duration throughout execution.



Complete Load Balancer statistics including
:

o

Balancing (among 3 webservers) throughout execution.

o

Number of sessions for each of the three webservers being used
throughout execution.

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
6

of
9

Last
Updated
-

11/1/13


o

Normalized response time of TCP connections between LoadRunner
clients and the webservers. This is translated via a
n algorithm to be an
indicator of average load on the webservers.



Complete Oracle Database statistics including:

o

Total number of sessions

o

Number of active sessions

o

Total number of sessions waiting on non
-
idle events

o

Total number of latch free wait events

o

Total number of waits for blocking locks (enqueues)

o

Total number of waits for busy memory buffers

o

Total amount of PGA allocated memory in use in MB

o

Total amount of PGA memory in MB used at that moment

o

Number of commits between time intervals



Complete AIX O
perating System Statistics for all servers in the architecture
including:

o

User CPU used

o

System CPU used

o

Idle CPU

o

Memory paging statistics

o

Total memory consumption

o

NETSTAT statistics (infrequent due to resource consumption)



Complete Network Statistics

o

Throu
ghput between all hosts in the architecture

o

Latency between all hosts in the architecture




IV. Assumptions and Risks for The Upgrade System Test
Approach



Transactions


Eleven transactions have been identified as development not ready by 4/24/03 releas
e
migration. They are listed as follows with an associated risk option (description can be
found in table below list):


Name of Transaction

Development Schedule

Option

HR Job Requisition

Scheduled to be complete
by 4/30/03


A

HR Manage Competencies


Scheduled to be complete
by 5/31/03

B

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
7

of
9

Last
Updated
-

11/1/13


HR Change Worksheet

Not scheduled to be
complete until 7/31/03


D

DW Extract for Student
Records

Scheduled to be complete
by 5/31

B

FASF Self Service E Perkins

Scheduled to be complete
by 6/01/03

B

FASF Self Service Acct
Summary

Scheduled to be complete
by 6/01/03

B

FASF Review Customer
Info

Scheduled to be complete
by 6/01/03

B

FASF Tuition Calculation

Dependent on SRCA
student enrollment

E

SRCA Class Roster

Possibility of completion by
4/24

A,B

SRCA Backpack

Meeting on issues 4/8


SRCA Enrollment Request

Dependent somewhat on
Backpack; completion

estimated at late June; some
combo of custom and

vanilla could be used for
load testing


D,E





Option

Solution

Pros

Cons

A

Transaction is ready
after 4/24 but prior to
6/2 start date

Object could be
migrated to
HEWORK1, tested
and then migrated to
HEWORK2, script
would have to be
written

Could still
possibly test in
later cycles of
load test

Object is not
properly tested
or scripted and
corrupts o
ther
testing

B

Transaction is ready
after 6/2 but prior to
7/18 end date

If enough weeks
were left, object
could be migrated to
HEWORK1, tested
and then migrated to
HEWORK2, script
would have to be
written

Could still
possibly test in
later cycles of
load

test

Object is not
properly tested
or scripted and
corrupts other
testing

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
8

of
9

Last
Updated
-

11/1/13


C

Transaction will not be
ready in load test cycle

Vanilla functionality
could be substituted
in load test

Basic
functionality
could still be
simulated and
tested

Real
functionalit
y
would not be
tested; another
object may be
dependent on
object that is not
ready

D

Transaction will not be
ready in cycle and
vanilla functionality
cannot be substituted

No solution evident


Functionality
will not be
tested.

E

Transaction ready but
dependent on another
transactions
development

Modules would
have to coordinate
version of
transactions to work
together in testing

Transactions
could still be
included in test

Real
functionality
would not be
tested; another
object may be
dependent on
objec
t that is not
ready



V. Deliverables




Work Breakdown Structure (WBS)
-

updated business processes and adjusted
hours. This is required at the beginning of the system test phase, in order to put
the WBS into planview for tracking and reporting.



M571


System Test Plan

o

Master reusable test plan (RTPs) with appropriate rating scale assigned to
each business process.

o

Test scripts and process flows as necessary

o

All internal and external touch points/interfaces and key contacts must
be identified.



STAT
-

O
MR



TI (Testing Instance) Database (Resolution of issues or work around in place)



M521


Load Test Functional Requirements



M522


Load Test Transaction Description

Information
and Technology
Services

PeopleSoft Upgrade Project


M 5000A3


Load Test Approach Document





mountainrome_ad185c3e
-
9bb3
-
4fad
-
909b
-
828c4636d2c6.docx

P
age
9

of
9

Last
Updated
-

11/1/13




M523


Load Test Infrastructure Change Logs



M53
8



Load

Test Status Report

We will provide a

daily status of Load Test executions. Th
is

report will include
information on the following:

o

Specific information on Load Test executions completed that day with
some detailed information regarding specific outcomes

o

Progress made toward goals as stated i
n this document

o

Outstanding issues

o

Decisions and action items




Final Report

(M??????????????????????????)

The TIO Load Test team in conjunction with CPU representatives will produce a
comprehensive report on all executions, achievement of goals, final
analysis of
this phase of the Load Test as a whole, and final conclusions.