You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Starting with release 11.0 Blueriq decided to introduce a forms performance report. Triggered by the new external session storage development this report doesn't serve solely the purpose of offering performance information to clients that use Blueriq forms exclusively (without any additional components like dashboards, process engine etc) but also compares and assesses the response times for the memory and external session implementations.

 

Because generally forms tend to be lighter on the memory consumption than other components it was decided to simulate a higher user load. This method assures that the differences in response times are clearer and less circumstantial and helps us draw some conclusions on the use limitations in a certain given environment with some certain given settings. In this way we learned for instance that the Runtime is slightly faster with an inmemory session keeping but on the other hand it supports a lower amount of users.

 

 

This happens because ... Petru Galanton can you please fill up this phrase?

 

Returning to the user load it is important to say that the 2 attached reports are depicting a run with 450 threads (for the memory run) and a run with 800 threads respectively (for the redis run). Both runs are holding the load for 1 hour. As for the results themselves they are interpreted in the same study measurement way as the other Blueriq performance tests namely with the help of Apdex. This page will not explore this subject any further as there is already a special section created just for that [Click here read about Apdex].

Information on the reference application

 

In order for us to obtain relevant test results we needed to have a Blueriq application very much similar to a real application in production. Thus we aimed at having as much elements as possible (required fields, conditional fields, field validations, file upload/download containers etc) but also a reasonable profile size. The application poses as a bank website where the user can either search and find the available ATMs in his area or apply for one of the three available loans.

 

 

The performance script carries the user from logging in, to searching for available ATMs (this is the moment where 500 instances are created - each of them containing 5 attributes), applying for a loan, filling fields, switching pages, uploading and downloading files and eventually logging back out of the application. It is this script that helped us in finding and resolving some forms performance issues and also in drawing some conclusions about Blueriq performance in general.

 

For the rest of it the attached documents should self explanatory.

 

 

 

  • No labels