PeopleSoft Load Testing Using JMeter

Transcription

1 PeopleSoft Load Testing Using JMeter

2 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.

3 Load Testing - Goals Access the Production Readiness o Check the system response time during expected load conditions o System behavior during unexpected load conditions o Check the system scalability o Best configuration settings for optimal performance o System behavior during spike user loads o 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

4 Drivers and Success Factors

5 Architecture

6 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 HCM FSCM CS 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 Journal e-procurement Create Requisition Punch out process Approve requisitions e-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

7 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

8 Making it Real, for the University

9 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) 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) View Pay Check View W Direct Deposit changes W2 Consent Submit W Updates beneficiaries View Benefits summary Benefit Election review The number against each process is percentage of failures during load test. Not Executed : Might lead to system unavailability

10 View Paycheck Response time As depicted 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 60% of failures during the load test.

11 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.

12 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. Users (Employee) 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 The number against each process is percentage of failures during load test. Not Executed : Might lead to system unavailability

13 Create Suppliers Response Time In this graph as you can see we see only one thread (PINK) was elevated and all other threads are flat Which 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.

14 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.

15 Campus Solutions Load Test All the tests are done through ihub portal 3 Categories Faculty, Staff and Student Self Service Users (Faculty & Staff) Register Student Modify Biodemographics 0 50 Not Executed Run Transcirpt Not Executed Search Classes Post Grades Track Attendance 0 30 Not Executed View Class Roster Not Executed Users (Student) Add Class Search For Open Class from Home Page Search For Open Class with Student Login View My Class Schedule View My Grades View Tuition Calculations Make Payment View Financial Aid The number against each process is percentage of failures during load test. Blank means there are no failures

16 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.

17 Tuition Calculation 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.

18 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

19 Contact us for a quick demo Thank You Suresh Katamreddy Phone: suresh@kastechssg.com