PeopleSoft Load Testing Using JMeter

Overview

Obtain baseline performance profile for the PeopleSoft systems

Ensure the PeopleSoft Applications have adequate capacity to support the user loads

Confirm web servers, application servers, database server and subsystems are configured for optimal performance

Identify on-line stress points or system bottlenecks where application performance degrades to an unacceptable level

Validate the available CPU capacity is adequate to meet the transient load during Peak Load periods

Provide recommended changes based on Oracle best practice and our experience in providing this type of service.

Load Testing - Goals

• Access the Production Readinesso Check the system response time during expected load conditionso System behavior during unexpected load conditionso Check the system scalabilityo Best configuration settings for optimal performanceo System behavior during spike user loadso System stability

• Compare two platforms with the same software to see which performs better

• Compare Performance characteristics of system configurations

• Evaluate System against performance criteria

• Find throughput level

• Discover what parts of the application perform poorly and under what conditions

• Finding the source of performance problems

• Support system tuning

Drivers and Success Factors

Architecture

Transactions Considered

• New Hire Process• Promotions• Demotions• Standard Hours

Changes• Leave of Absence

changes• Transfers• Terminations• Job Data Inquiry• Benefit Changes• Life Event Changes• Address Changes• Personal Data

Inquiry

e-Pay transactions• View Pay Check• View W2• Direct Deposit changes• W2 Consent• Submit W4

e-Benefits Transactions• Add Life Events• Updates beneficiaries• View Benefits

summary• Name change• Benefit Election

review

• Enter Requisitions• Approve Requisition• Create PO• PO Approval Process• Dispatch PO• Source Requisitions to

PO• Create Voucher• Create Journale-Procurement• Create Requisition• Punch out process• Approve requisitionse-Supplier• Enter suppliers• Approvals• Updates• Deletes

• Add 4 Courses• Ad hoc add course• Search with 2 criteria• Search for specific

section• Account Inquiry after

add classes• Drop Class• Swap Class• Unofficial Transcript• Calendar Inquiry• Modify Personal Data• Lookup teaching

schedule• Approve Grade Sheet• Lookup Class Roster

HCM FSCM CS

Metrics & Stats

JMeter provides the following distinctive features

for monitoring and viewing the Metrics & stats.

• Thread/Virtual Users Metrics• Response Times Metrics• Results Monitoring• Generating Report Dashboard• Real Time results

JMeter comes with a GraphiteBackendListenerClient which

allows to send metrics to a Graphite Backend. This feature

provides:

• Live results• Nice graphs for metrics• Ability to compare 2 or more load tests• Storing monitoring data as long as JMeter results in the

same backend• JMeter can measure Elapsed Time, Latency, Connect

Time and Throughput

Making it Real, for the University

HCM Load test

• All the tests are done through iHUB portal• HCM Load test are done for Managed and Self service processes• Managed – 300& 500 user load• Self Service – 500, 1000 & 1500

Users (Managed) 300 500

New Hire Process 0 0

Job Data Inquiry 0 0

Address Changes 0 0

Personal Data Inquiry 0 0

Leave of Absence changes 0 0

Transfers 0 0

Terminations 0 0

Name change 0 0

Life Even Change 0 0

Users (Self Service) 500 1000 1500

View Pay Check 0 0 60

View W2 0 38 33

Direct Deposit changes 0 0 40

W2 Consent 0 0 50

Submit W4 0 0 45

Updates beneficiaries 0 0 40

View Benefits summary 0 0 40

Benefit Election review 0 0 30

• The number against each process is percentage of failures during load test.• Not Executed : Might lead to system unavailability

View Paycheck – Response time

As depicted in graph there morethreads/users are queued up over150 seconds and application didnot respond which turned out tobe connection time and that’sreason with load of 1500 , we see60% of failures during the load test.

View Paycheck – Time vs Threads

Average response time in this graph is pretty much over 150 Second and seems like users are timed our when lots of users are queued up over this wait time.

FSCM Load Test

• All the tests are done through iHUB portal• Two cycles of Load testing • First one with 300 and second cycle is with 500 users with ramp up period 0.05 seconds.

• The number against each process is percentage of failures during load test.• Not Executed : Might lead to system unavailability

Users (Employee) 300 500

Enter Requisitions 0 0

Create PO 0 0

Dispatch PO 30 Not Executed

Create Voucher 0 0

Create Journal  0 0

Create Requisition 0 0

Create suppliers 0 0

Updates suppliers 0 0

Deletes suppliers 0 0

Create Suppliers – Response Time

In this graph as you can see we see only one thread (PINK) was elevated and all other threads are flatWhich mean for this there is consistent response from Application and we didn’t see any issue during this load test.Also observe that the single thread is just over 150 Seconds response time.

Create Suppliers – Time vs Threads

Average response time in this graph was pretty much below 150 Second and seems like users are not timed out on average response time.

Campus Solutions Load Test

• All the tests are done through iHUB portal• 3 Categories – Faculty, Staff and Student Self Service

• The number against each process is percentage of failures during load test.• Blank means there are no failures

Users (Faculty & Staff) 500 750 1000

Register Student 0 35 80

Modify Biodemographics 0 50 Not Executed

Run Transcirpt 40 65 Not Executed

Search Classes 30 10 50

Post Grades 0 30 55

Track Attendance 0 30 Not Executed

View Class Roster 40 60 Not Executed

Users (Student) 500 1000 1500

Add Class 0 0 0

Search For Open Class from Home Page 0 0 25

Search For Open Class with Student Login 0 0 0

View My Class Schedule 0 0 40

View My Grades 0 0 25

View Tuition Calculations 0 0 30

Make Payment 0 0 25

View Financial Aid 0 0 0

Tuition Calculation – Response Time

As seen in graph there more threads/users are queued up over 150 seconds and application did not respond which turned out to be connection time and that’s reason with load of 1500 , we see 30% of failures during the load test.

Tuition Calculation – Time vs Threads

Average response time inthis graph is pretty muchover 150 Second andseems like users aretimed our when lots ofusers are queued up overthis wait time.

Recommendations

• Consider lowering the Max Clients per handler parameter to 20 and increase the amount of Max Handlers to compensate.

• Consider lowering the Client Cleanup Timeout to 10 in order to save system resources

• Consider setting DumpMemoryImageAtCrash to MINI in order to have additional details when a crash occurs

• Decrease Recycle Count to 5000 for PSAPPSRV Servers.

• Use Centralized gateway for integration Broker

• Enable IB Error Notification in integration broker

Thank You

Contact us for a quick demo

Suresh Katamreddy

Phone: +1 210 859 3259

suresh@kastechssg.com

www.kastechssg.com