Performance Test Summary Report, Slides of Business Accounting

This is to test with a single user over a period of time to find out the best possible time for the application to be performance tested.

Typology: Slides

2021/2022

Uploaded on 07/05/2022

lee_95
lee_95 🇦🇺

4.6

(59)

999 documents

1 / 13

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Performance Test Summary Report
<Department Name>
<Project Name>
<Version Number>
pf3
pf4
pf5
pf8
pf9
pfa
pfd

Partial preview of the text

Download Performance Test Summary Report and more Slides Business Accounting in PDF only on Docsity!

Performance Test Summary Report

Document history

Date Version Author Reviewed by Approved by Description

1 Introduction

1.1 Engagement

1.2 Objective of the report

1.3 Intended audience

2 Scope of Performance Testing

3 Test Approach and Methodology

The following sections describe in detail the devised strategy to execute the performance test activity of .

Approach

The following types of performance tests were planned in order to exercise the system fully to ensure that the required performance SLAs are met. These tests are also designed with the aim of exposing the maximum number of performance bottlenecks. Based on the identified test scenarios following kinds of tests were created.

1. Best Case Scenario This is to test with a single user over a period of time to find out the best possible time for the application to be performance tested. Application would be loaded with a single user activity and corresponding performance metrics would be gathered against it. This is primarily to ensure that the scripts will execute end to end without any issues. 2. Baseline Test Each application workflow identified in the performance critical list will be executed with a peak load in the full configuration of the system in isolation with no other concurrent load with the aim of getting the baseline performance metrics. During this test execution, application performance would be monitored to gather the critical metrics like CPU Utilization, Memory Utilization, Network/ Bandwidth usage etc. 3. Spike Test This Test will be executed on the environment to ensure that the IT System is capable enough of handling sudden load in exceptional conditions. This would demonstrate system’s ability to deal with large number of requests in short span of time, to which the current system architecture can sustain itself. This would be achieved by applying a step user load on a stable running condition.

Performance Test Summary Report 5 During this test execution, application performance would be monitored to gather the critical metrics like CPU Utilization, Memory Utilization, Network/ Bandwidth usage etc.

4. Stress Test If the Baseline test achieves satisfactory performance, a separate Test will be executed on the environment to ensure that the IT System is capable enough of handling excess load in exceptional conditions. This would establish the load limit, to which the current system architecture can sustain itself. This was achieved by increasing the User Load by around 100%, 200% and 400% of its expected usage and Transactional Load.

Methodology

The methodology of the performance analysis activates are mentioned below: Requirement Gathering

  • IdentificationofHighP
  • Identificationofareaso
  • Identificationofareast
  • IssuesforScriptingand Script Preparation
  • Parameterizationandc
  • DatapreparationorAcc
  • Toensureerrorfreerun
  • ExecutethemwithLoa Performance TestExecution
  • Responsetimesofeach performancetestingwe
  • TestResult(Data,Grap Server Monitoring
  • PerformanceMonitoru
  • Apluginwasalsoadded
  • Accumulationofvariou
  • Unixcommandexecuti
  • DataCollectionforRep Report Preparation
  • FinalizationofReportS
  • Completionofapproac
  • Annexurepreparationa •FinalReport. riority,CriticalBusinessTransactions. fmodificationtotheOutoftheBoxproduct. hatareresourceintensive. loadtestingwereidentifiedandalternativesolutionw orrelationoftherecordedscripts. umulationforTestingPurpose ofthescripts. dandNoloadconditionsformultipleiterations. transactionalongwithallothernecessaryparameters remeasured. hetc)collection. tilityofwindowswasusedtomonitorperformancepar withJMetertomonitorperformance. sutilizationreports,statisticalreportsduringPerforma oninconsoletohavecriticalprocessIDs. ort. tructure. h,methodology,observation,conclusionsandotherdeta ndAnalysis. orkedout. pertainingto ameter. ncetesting. ils.

Performance Test Summary Report 7

4 Test Environment and Configuration

Test Environment will be used for performance test execution. As there is a difference between configuration of Test Environment and actual production environment, there is a scope of extrapolation of test result. Hence the identification of bottleneck and recommendations will be made at high level.

4.1 Test Environment

The test environment is the designated performance testing environment for Portal performance testing. The following table lists the hardware and software configuration of the Portal Stage and Production environment. Application Component Host Name Operating System CPU Type # of CPU RAM Software Proxy Server PROX YSRV.lo caldom ain RHEL Version 5.5 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 4 Core(s), 4 Logical Processor(s) 8 32GB Apache Tomcat Application, DB and CMS Server

- APPSRV.l ocald omain RHEL Version 5. Intel(R) Xeon(R) CPU E5620 @ 2.40GHz, 4 Core(s), 4 Logical Processor(s) 8 64GB JBoss, Alfresco, MySQL Test environment was connected with Load generator through Checkpoint VPN network.

4.2Load Generator System Configuration

Test was conducted from a machine of following configuration – Processor – Intel(R) Core(TM)2 i5-3340M CPU @ 2.70GHz RAM details – 8 GB Hard Disk Details – 256 GB SSD Operating System – Windows 7 professional 64 bit Test Database Details – MySQL and SQLYog System Type – 64 bit

4.3Performance Monitoring

During each test execution, pre-defined performance metrics will be monitored and analyzed to ensure compliance to performance SLAs and to detect bottlenecks in the various application components. The performance metrics that would be monitored fall under one of the following three broad categories:  Response and Elapsed Time  Throughput / Hits  Resource Utilization (Infrastructure)

  • Response and Elapsed Time

End user response time for Portal will be monitored and measured for all the end user transactions using performance testing tool.

  • Throughput/Hits Throughput is defined as the number of departures past a given point per unit time. Throughput metrics pertaining to the rate of requests served from the Portal server would be monitored over the test period.
  • Resource Utilization (Infrastructure) The following resource utilization metrics will be monitored and measured during all the performance tests on all the servers that are part of the IT System Infrastructure to ensure that there are no capacity bottlenecks.  Processor Utilization  Memory Utilization  Disk I/O statistics (Rates, Wait times) would be monitored for server. This eventually contributes to a large extent for bad application performance Tests were carried out over the Nepal VPN assuming that the Network bandwidth is good enough to support the defined Load.

4.4Performance Test Tool Details

Apache JMeter 2.9 was used to conduct performance testing. The Apache JMeter desktop application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions. Apache JMeter can be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. It can be used to make a graphical analysis of performance or to test server/script/object behavior under heavy concurrent load.

4.5Test Configuration for Baseline Test

Scenario configuration details for baseline load testing consisting of all the test scripts. Script parameter details are noted in the table below: Sl No Test Script Total Vusers during Test Transaction rate(per Hour per Vuser) Think Time (in seconds) Total Ramp up Time (in mins) 1 Procurement Document Creation

2 Bid Submission 75 50 30 20 Detailed Load calculation for each module and each test has been mentioned in Annexure 1.

5 Test Execution Summary

5.1 Execution Summary

The test is conducted to observe the system behavior for a load of 100 Virtual Users.

Transaction Name _ BidCreate _03_BidSchedule _ BidCreate _04_CoverPage _ BidCreate _14_CreateBid _ BidSubmission _05_AnnualTurnoverForm _ BidSubmission _06_FinancialResourceForm _ BidSubmission _09_ManufacturerAuthLetter _ BidSubmission _12_Payment The detailed response time for 100 User’s Test is attached in Annexure 1. 5.2.1 Performance Test Server Analysis Test was conducted over a period of 60 minutes with a load of 100 concurrent virtual users. The CPU Utilization snapshot of the Performance Test Servers was also collected during the test. On analyzing the CPU Utilization snapshots, following can be interpreted: The server was showing an average CPU utilization of 17.313% under load. Maximum CPU utilization reached around 50% line frequently during the test. The CPU Utilization and other system resources snapshot for 100 User’s Test is attached in the

Annexure 1.

11 Nepal Performance Test Summary Report

5.3 Test Analysis - Graphical

Graphical analysis of the Server Performance was analyzed during the Test execution. The details are listed below: 5.3.1 Response Analysis and CPU Utilization of Servers

Annexure

Annexure 1 - Performance Test Report (Mandatory)

Performance Test report based on any standard tool should be attached in this section.