Transactional Density

This topic is only applicable to on-premises installations.

Transactional density is a variable factor that affects the performance of your Archer deployment. The average number of concurrent users divided by the average delay between the actions each user performs in the Archer web application equals the transactional density for your environment. While services and browser components also affect performance measurements, most user interactions with the Archer Platform take place over an HTTP GET/POST paradigm, so it is important to consider the implications of this paradigm when simulating load during performance testing.

With some exceptions, a user who is logged into the user interface but not actively performing actions does not generate load on the web server. For example, there is no performance impact while a user reads a page that has already loaded or while the user types into the fields on a page. Creating user sessions and reserving memory for each session generates some overhead on the web server. However, this load applies concurrently to the Archer Platform only when users send traffic over the network, such as by clicking Save to commit changes on a page or by entering data in a field that triggers a Data Driven Event (DDE).

When testing performance in your existing Archer deployment, or determining hardware requirements when planning a new deployment, it is recommended that you estimate transactional density using predictable values, such as a set number of users that perform a series of defined tasks repeatedly and at a specific frequency. This method creates an artificially high transactional density, because real world users typically pause while inputting data or take breaks between performing tasks.

Using this recommended evaluation method, the performance metrics captured for an environment with 200 concurrent users and a 10 second average delay between actions are approximately equivalent to metrics for 1000 concurrent users with a 50 second average delay.