HeaderSIS.jpg

IS480 Team wiki: 2013T2 D'PENZ Performance Testing

From IS480
Revision as of 21:29, 21 April 2014 by Elmaliqueg.2011 (talk | contribs) (→‎Analysis: Edit Project)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Dpenz logo.jpg

Neophase Home.png Home DPENZ Team Icon 2.png Our Team DPENZ Overview Icon.png Project Overview DPENZ Project Management Icon.png Project Management DPENZ Project Documentation Icon.png Project Documentation


Use Cases Architectural & Deployment Diagram Prototypes User Testing Performance Testing Presentation Slides Meeting Minutes Handover Documents



Performance Testing

Goal

Measure Response time and Throughput for the following purposes;

  • Measure limit of our application
  • Understand effects of Connection Pooling


Areas of Testing

Given the time constraint, we tested the areas that were the most used features:

  • Create Project
  • Edit Project


Step Load Test

Rationale: More realistic demand on the server
Initial User Count: 100
Step Duration: 60 Seconds
Step User Count: 25,50,75,100,125
Maximum User Count: 3000 (Asia-Pacific User Base)


Connection Pooling (CP)

A connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools are used to enhance the performance of executing commands on a database. Opening and maintaining a database connection for each user, especially requests made to a dynamic database-driven website application, is costly and wastes resources. In connection pooling, after a connection is created, it is placed in the pool and it is used over again so that a new connection does not have to be established. If all the connections are being used, a new connection is made and is added to the pool. Connection pooling also cuts down on the amount of time a user must wait to establish a connection to the database.


Results: Create Project

Throughput Response Time
TPCTAfter.PNG
RTCTAfter.PNG


Analysis: Create Project

On average, there is an improvement of 78% in the response time and a 57% improvement in the throughput. This can be attributed to the increase in number of database connections and subsequent re-usage.

OverallImprovementCT.PNG

AverageImprovementCT.PNG

Result: Edit Project

Throughput (After CP) Response Time (After CP)
TPETAfter.PNG
RTETAfter.PNG

Analysis: Edit Project

On average, there is an improvement of 78% in the response time and a 57% improvement in the throughput. This can similarly be attributed to the increase in number of database connections and subsequent re-usage. However the figures are smaller because for edit there are more connections to the database being used for not only read but also writing.

OverallImprovementET.PNG

AverageImprovementET.PNG

Limitation of Testing

Application is not deployed on the client site.

Moving Forward

  • Deploy it on the client side
  • Conduct our testing on more areas