Generally, we aim to test the products in their default configurations unless they are not suitable for the test. In our containerized environment, however, there are two concurrency-related settings that we change from their default values.
Following best practices for serving HTTP traffic with the software running in containers, all test workloads are submitted to the integration servers under test through their embedded HTTP listeners. To make best use of the available CPU capacity, we tune the “ListenerThreads” property of the HTTPConnector Resource Manager in the integration server, configurable via the server.conf.yaml configuration file. This setting determines the number of threads used by the HTTP listener to serve HTTP traffic. We set this value to 2 on Linux and 1 on Windows. This setting only applies to the tests running on IBM App Connect Enterprise Version 11, but not those on IBM Integration Bus Version 10, where all listener configuration parameters take their default values.
With the goal of efficiently using the CPU, we also tune the “Additional instances” property of message flows under the Workload Management group of configuration options, which we always set in line with the concurrency requirements of the test being performed. For each test, we set the total number of message flow instances to three times the number of virtual CPU cores configured on the server container. For our tests, this is a reasonable compromise between excessive context switching overhead and having too few threads to serve the inbound workload.