Best Practice: Operating Within the Connection Threshold for Hosted CLS Instances
Best Practice: Operating Within the Connection Threshold for Hosted CLS Instances
Purpose
As part of implementation planning, FlexNet Operations tenants who will host FlexNet Embedded CLS instances on the Revenera Cloud need to be aware that a pre-defined threshold for concurrent connections to CLS instances is enforced per tenant. This same threshold applies to every tenant. If the threshold is too restrictive for those tenants who deal with large numbers of CLS connections, Revenera provides some best practices to help these tenants still successfully operate.
Need to Know
The following information defines the term "connection" and identifies the current threshold value for connections to CLS instances.
Definition of "connection"
A connection is defined as a single request-response exchange of data between a FlexNet Embedded client (belonging to a licensed customer of the tenant) and the CLS instance set up for that customer. As an example, suppose the client instance performs the following:
Previews the features currently available to the client.
Obtains the available features from the CLS through a capability request.
Views a list of all the features currently installed on the client instance.
Each task in the above list represents a single connection, involving a request sent to the CLS from a client and a response sent from the CLS back to the client.
Thresholds Enforced for Concurrent Connections
A given FlexNet Operations tenant can have one or more CLS instances per customer. Historically, the customer implementations for any tenant can experience surges of connection activity that result in feature contention on the License Server database in the Revenera Cloud. Unfortunately, these surges can impact other tenants.
To help avoid the potential for contention among the CLS instances across tenants, Revenera has applied a mod_qos control at the Web Server level on the Revenera Cloud. This control—enforced for very tenant—allows a maximum number of 60 concurrent connections across all CLS instances for a given tenant. (For more information about mod_qos controls, see https://en.wikipedia.org/wiki/Mod_qos.)
Whenever the total number of concurrent connections for a tenant surpasses this threshold, subsequent requests are immediately dropped until more connections open up.
Note that CapRequest, the most-used license server call, has an average response time of only 57 milliseconds. If a single connection can respond in 57 milliseconds, then new connections can be added fairly rapidly as others end. From another perspective, if a tenant reaches the 60-connection threshold, a new connection can be added in 57 milliseconds or less.
Best Practices for Working Within the Threshold
The following are best practices that a tenant or SRE can put in place for the tenant's customers should the maximum number of 60 concurrent connections at any given time be too restrictive:
Limit the rate at which checkouts arrive at the CLS. For example, you could impose a longer checkout period—or have FlexNet Embedded clients borrow licenses—rather than use a rapid checkout-checkin cycle
Allow retries whenever a request fails, especially if a site is making a series of requests within one flow. Without retries, if one request fails, the entire flow must be repeated. However, if retries are allowed, the remaining successful requests in the flow can proceed without having to be repeated.
If retries of failed requests are permitted, pause before retrying to send a request. (Perhaps apply a back-off policy to increase the pause between retries of a request.)
