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.

4 comments on"Optimization and Tuning"

  1. Hi Geza,
    Is the property to add Listener threads in the sever.conf.yaml file in 11.0.0.5 . I am using 11.0.0.4 and couldnt see this attribute under the httpconnector information. Could you please provide more detail of how this can be done.

    HTTPConnector:
    #ListenerPort: 0 # Set non-zero to set a specific port, defaults to 7800
    #ListenerAddress: ‘0.0.0.0’ # Set the IP address for the listener to listen on. Default is to listen on all addresses
    #CORSEnabled: false # Set the value to true to make the listener respond to valid HTTP CORS requests
    #CORSAllowOrigins: ‘*’
    #CORSAllowCredentials: false
    #CORSExposeHeaders: ‘Content-Type’
    #CORSMaxAge: -1
    #CORSAllowMethods: ‘GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS’
    #CORSAllowHeaders: ‘Accept,Accept-Language,Content-Language,Content-Type’

    Thanks

  2. Can you explain how the values for HTTP threads and additional instances are determined?

    • Geza Geleji June 10, 2019

      Mostly on an empirical basis, with the goal of having as few threads as possible while still making full use of the available CPU capacity.

Join The Discussion

Your email address will not be published. Required fields are marked *