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
www.kastechssg.com