Load Testing

We have run many load test scenarios that simulate real-world usage of the product and also customer specific scenarios. One recent example we ran for a global bank required us to show how much load could be tolerated on a single server setup (database, application, reporting and Connection Agent all on one box).

The setup we ran used had the following configuration

  • Dual Core Single CPU XEON 2.99 Ghz 
  • 2Gb Ram
  • Plenty of disk space
  • SQL Server 2005
  • IIS
  • PerfectForms On Premise
  • PerfectForms Connection Agent running under Tomcat 6.0

 

The Environment

You should note that all these tests are run on a dedicated local area network in order to remove any poor performance due to network or internet issues. This ensures that the servers get fully loaded but you should also be aware that real world users will see slower response times as they will often be remote from the servers and so network response times need to be factored in.

Large companies will often find that their perceived performance is slower if they have heavily loaded networks or other bottlenecks that are outside the PerfectForms sphere of influence.

 

The Form

We are using a typical 4 page customer form that requires a user login to access it. Once logged in, the form performs a database lookup that retrieves data back into the form.

 

  • Typical 4-page Form requiring a user login
  • Once the form is loaded, 5 background database lookups are performed for each Form Instance.
  • We then add more logins until 300 requests have been processed
  • 20 users submit data from the form (no natural delay is built into the test to maximize the load on the server)
  • 280 users login to the form and then immediately close it without submitting any data, but the  database lookup is still done.
  • This test runs indefinitely processing 300 users at a time with 20 new form submissions taking place. The rest are assumed to be people looking at the form.
  • Each form login, the enture PerfectForms Player is transferred across the network (1.2Mb). In most circumstances, this would be cached.


Summary Findings

  • CPU fluctuates between 10% and 30% with some occasional and brief bursts beyond this range.
  • No form errors of any kind under peak load
  • During one hour, the load test generated 8'437 form transactions.
  • This equates to a normal load of at least 84'000 forms in one hour if the load were generated by humans as opposed to load testing software (where we had no think delays for form completion; assumes a ratio of 10:1)
  • This form has 5 lookups being performed for each login, which is unnaturally high and generates considerable extra load
  • This test has all components on one single werver with only 2Gb RAM for the application, database, connection agent and reporting. Each of these components can be split onto seperate servers if required.
  • Load balancing can be applied to the application which will lead to major scalability