Child pages
  • Tuning IG and the ClientHandler/ ReverseProxyHandler
Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

Version 1 Next »

IG ClientHandler and ReverseProxyHandler Configuration

The IG ClientHandler and ReverseProxyHandler is configured to communicate as the client to the downstream protected application.

Specific configuration that manages this communication are:

OptionDescription
connectionsThe number of available connections to the downstream remote application
numberOfWorkersThis is the number of IG worker threads allocated to service inbound requests and manage propagation to the downstream application. Of note, IG has an asynchronous threading-model, so a worker thread is not consumed blocking for a response from the downstream server.
connectTimeoutThe connection timeout, or maximum time to connect to a server-side socket, before timing out and abandoning the connection attempt.
soTimeoutThe socket timeout, or the maximum time a request is expected to take before a response is received. The request expires if this timeout is breeched.


Configuring IG on Tomcat

The Tomcat maxThreads is the number of Tomcat HTTP request threads, as stated. The IG worker threads - numberOfWorkers  - will pick up from the Tomcat request threads to propagate requests for processing downstream.

Tomcat IG container and IG configuration should be done with regard to:

  • The downstream remote application configuration - possibly Tomcat configuration - to ensure it can support the expected downstream application configuration.
  • It should be noted too that the configuration of the downstream container will limit the performance of IG (and its container).
  • Constraints on the available hardware, CPU, memory and JVM config are also factors - but this its typical and understood.
  • IG typically is not memory-intensive, being a proxy. Typical usages, including documents of 500Mb found that IG rarely Enabling caching and up/ downloading of large messages will not cause the JVM to allocate more than 5Gb NewGen space. OldGen space is not particularly utilised.
  • Enabling IG caches and larger request/ response document sizes do increase memory requirements, so pre-production testing with real-world use cases should be conducted to ratify any assumptions.

Further to that, the version of Tomcat and the selection of Tomcat HTTP Connector is very important with regards to configuring IG. Notably, IG should be configured in conjunction with the Tomcat IG container configuration. Notably:

  • If using a BIO Connector (Tomcat 3.x to 8.x):
    • the Tomcat maxThreads should be aligned to be close to the number of Tomcat configured connections. IG can be configured a lot lower (using an async threading model). The async IG threads are freed up immediately after the request is propagated and can service another blocking Tomcat request thread.
    • Assumptions should be ratified in a pre-production performance test environment using real-life use cases.
  • If using a NIO Connector:
    • Tomcat maxThreads config can be a lot lower than it would be using a BIO Connector. The NIO Connector also uses an async threading model, freeing up request threads once the request is handed over to the IG worker threads.
    • Therefore, the config of IG worker threads - numberOfWorkers should be closely aligned with your Tomcat request threads - maxThreads.
    • It is still necessary to test the IG worker config throughput/ errors incrementally in this deployment to identify optimum throughput.

Configuring IG Standalone



  • No labels