A key component of the output from any rule set execution is the performance data. The performance data tells you exactly what happened inside your rules.

It is important to understand what influences the rules performance. For example, database delays, the user of external/networked services, the need to call the underlying application (as done by the HTTP Response Addition and HTTP Server Execute rules) all can add considerable transaction delays beyond the control of Composable Architecture Platform.

If your performance collection level is set to "Transaction count and inline time" in your configuration, you will get additional information about the time spent inline in each rule. The following is an example from the Qwerty rules:

The time shown is always in ms (milliseconds) per transaction. If the time measured is less than 1 ms, 0 is shown.

Performance numbers below 10ms are shown in green, 10-50ms in yellow and more than 50 ms as red.

In terms of benchmarking, outcomes will obviously depend on the rule sets used. During benchmarking testing for the product, 8.4 million transactions per hour were achieved for a rule set that included:

• Geo location lookup for each IP address using the MaxMind Geo Location rule

• Keyed CSV lookup of a blacklist using the CSV Lookup Rule

• Storing of the last five and retrieval of the last two IP addresses using the History Recorder rule

• Numeric comparison using the Value Comparer rule

• Text substring comparison using the Value Comparer rule

• Console listing for 0.8% of the test data entries using the Attribute Lister rule

The throughput was achieved on an IBM 8-way 1.8 Ghz Power 5 system running AIX with the help of the Composable Architecture Platform in-built load balancer.

These performance numbers are not intended to serve as a promise regarding what can be achieved in any specific configuration. It is merely provided to give a feel for the overall performance capabilities that may be achieved.

The complete performance report is available when the performance collection level is set to "All counters". The full report includes all of the statistics described in the previous sections, plus a URI level report and database pool statistics

The database pool report provides a view of the size of the database pool and the number of live connections (connections handed out to the X Engine), spaced out over the life of the X Engine. The timeline will compress depending on the time the X Engine has been running.

The URI level report is divided into 2 sections. The first section provides a summary of the highest X Engine delays measured for each URI in descending order from the highest to the lowest. This measurement does NOT include the very first transaction for each URI. It is a useful measure to quickly identify rule set hot-spots in very large rule sets.

The second section provides a quick view of individual URI response times (or all URIs combined if "*" is selected). There are up to three of these distribution diagrams:

1. Performance with X Engine stopped. This diagram is only present if data has been collected with the X Engine stopped. This can be achieved by stopping a configuration and continuing to undertake transactions.

2. Performance with X Engine started. This diagram provides information about the combined delay of the application and the X Engine.

3. Performance of X Engine alone. This diagram provides information about the X Engine alone. Application response times are automatically deducted from the result. However, any calls to external services or databases are still included.

The amount of data you see will depend on the performance collection level set in the configuration deployed to the server.

For production environments with stable rule sets it is highly recommended to set the level to Transaction count only. Collecting performance information has an overhead on its own.

The performance information for each URI and each of the three distribution diagrams is the same. The details of each element is as follows:

The distribution diagrams show transactions below 100ms, below 1s and up to 20s. Transactions taking 20 seconds or more will all be included in the >=19 seconds group. These distribution diagrams are especially useful when combined with the transaction counts in the rule sets.

Click the View Rules Performance button to see the details. The diagram below shows an example for Qwerty:

The numbers shown next to the inputs and outputs for each rule represent the number of times a set of data entered and exited the rule. In the above example, 25 transactions entered the Initialization rule set, and the rule set filtered out 2 of those before sending 23 further through the rule set.

For content rule sets, a similar view of the transaction counts for that rule set can be viewed by clicking on the View Content Performance button.

For timer rule sets, a similar view of the transaction counts for any individually selected timer rule set from the drop-down list can be viewed by clicking on the View Timer Performance button.

To obtain the performance data for a given server, select it in the Composable Architecture Platform Servers folder and click on Get performance data.

The default name for the performance data is the name of the server. Enter a name and click the Retrieve button. Once the download is complete, you can see the performance data by clicking on the Performance Data folder and selecting the file name.