HTTP Request Management#
A HTTP Server’s fundamental job is to handle HTTP requests coming from clients efficiently.
To do that, it must have a strategy for how to do that as fast as possible while avoiding running out of resources, which could cause it to crash.
The Curity Identity Server has various features and configuration settings that enable administrators to choose the right strategy for their particular situation.
Notice that TPC connection management is discussed in the Accepting Incoming Connections page. This page focuses on HTTP Requests once they’ve been accepted by the HTTP Server’s Connector.
Configuring the number of request Threads#
It is possible to configure a minimum and maximum number of request Threads that the HTTP Server should allow at any given time. For convenience, that is done together with the Incoming Connections configuration. Refer to that page for information about how to configure that.
The number of Threads should reflect the expected traffic that each HTTP Server node is expected to handle. This is hard to predict, so we recommend to start with the default values, and adjust as information about resource consumption and request load becomes available.
To be able to accurately decide on how many Server Nodes to have, how much load each Node should be able to handle, the size of the physical/virtual machines that are required to host the nodes, it is important to monitor the Server as it operates.
See our documentation on Deployment and Operation and Monitoring for information about how to do that.
Since the HTTP Server is Java-based, it is also useful to monitor the JVM the Server is running on. Check the JVM Configuration page for details.
It is very important to ensure that the number of Request Threads is aligned with the number of Database connections that the connection pool may utilize. Depending on your Data Source, this should be configurable in the Data Source Configuration .
Basically, the maximum number of Database Connections should match, approximately, the maximum number of Request Threads. This ensures that the HTTP Server never chokes due to all HTTP Request Threads being blocked waiting for Database Connections to become available. If that happens, the Server may still have plenty of resources available, but still become unresponsive because no request Thread can make progress.
Monitoring#
It is possible to monitor the number of Request Threads running on each Server Node by enabling JMX.
See the JMX and Java Flight Recorder page.
There are also various statistics published via the Status Endpoint .
Configuration changes#
When configuration is changed, it may become necessary to restart the HTTP Server. For example, if the server’s TLS key is changed, or its port.
In such cases, the Curity Identity Server will stop accepting incoming requests, wait for all currently running requests to be handled, and then finally restart and allow the configuration change to go ahead.
This should not be done during periods of high load as it is highly likely to cause disturbances to end users.