Jump to: navigation, search

log-output-timeout

Section: health-service
Default Value: 0
Valid Values: Any integer from 0-86400
Changes Take Effect: Immediately


Specifies, in seconds, the period at the end of which Chat Server outputs health metrics to the log. A value of zero disables output.

log-output-proviso

Section: health-service
Default Value: update
Valid Values: always, update
Changes Take Effect: Immediately


Specifies how health metrics are printed in the log:
  • always: Metrics are printed in the log whenever the timeout specified by "log-output-timeout" expires.
  • update: Metrics are printed in the log only if they were recently updated.

log-output-content

Section: health-service
Default Value: set
Valid Values: all, new, set
Changes Take Effect: Immediately


Specifies which health metrics are printed in the log:
  • all: All defined metrics.
  • new: Metrics that were updated after the most recent output to the log.
  • set: Metrics with non-zero values (the default).
Attention: Deleting this option or setting it to an empty value resets the values of all cumulative health metrics to zero.

limits-restore-threshold

Section: settings
Default Value: 80
Valid Values: Any integer from 0-100
Changes Take Effect: Immediately


Specifies the level (as percentage of maximum value) which metric must drop below in order to restore the service.

limits-reached-report-scs

Section: settings
Default Value: true
Valid Values: true, false
Changes Take Effect: Immediately


With a value of "false" Chat Server does not send "SERVICE UNAVAILABLE" notifications to Solution Control Server when Chat Server reaches any of its configured load limits. This can prevent Chat Server from switching over when configured as primary/backup.

limit-for-sessions

Section: settings
Default Value: 1000
Valid Values: Any integer from 0-1000000
Changes Take Effect: Immediately


Defines the maximum number of chat sessions that Chat Server handles simultaneously.

limit-average-interval

Section: settings
Default Value: 15
Valid Values: Any integer from 0-1000000
Changes Take Effect: Immediately


Specifies the interval, in seconds, for calculating the average time it takes Chat Server to process an incoming request. A value of "0" disables the calculation. This interval is used to calculate the value for the option "limit-for-reply-delay".

limit-for-reply-delay

Section: settings
Default Value: 2000
Valid Values: Any integer from 0-1000000
Changes Take Effect: Immediately


Specifies the maximum possible delay, in milliseconds, required for Chat Server to process an incoming request. The delay is calculated as an average value over an interval defined by the option "limit-average-interval".

limit-for-flex-users

Section: settings
Default Value: 1001
Valid Values: Any integer from 0-1000000
Changes Take Effect: Immediately


Defines the maximum number of flex users that Chat Server handles simultaneously.

limits-control-enabled

Section: settings
Default Value: false
Valid Values: true, false
Changes Take Effect: Immediately


Enables (true) or disables (false) load restriction for Chat Server.

Sizing Guide, Setting Load Limits, and Health Monitoring

Sizing Guide

The following guidelines are recommended for a Genesys Chat solution running on a single host with two Intel Xeon 3.0 GHz processors. Observe these recommendations for an optimum (without significant delay) performance.

Item

Maximum

Message size

4 KB (Genesys Desktop limitation; Chat Server does not have this restriction.)

Transcript size

54 KB (Genesys Desktop limitation; Chat Server does not have this restriction.)

Concurrent sessions (in a realistic simple scenario)

1000 per Chat Server

Messages per second

50 (rare temporary peaks up to 150)

Sessions opened and closed per second

10 (rare temporary peaks up to 30)

Chat Server limits the maximum number of concurrent opened connections (for all protocol and participants) with:

  • 32768 on Linux.
  • 4096 on Windows.

When opening and closing the connection, Chat Server prints in the log the current number of opened connections (as "conns=").

Note: You can configure a timeout in Chat Server that prevents keeping unused connections open. Use the user-register-timeout option to set the maximum time between establishing the connection and receiving:

  • Either a basic protocol Register request
  • Or any flex protocol request

Connection Delay with Antivirus

It may take some time (up to several minutes on some UNIX Platforms) for Chat Server to connect to an unopened port on a Windows host that is running an antivirus program. For example, if Chat Server is running on Linux and is trying to connect to an inactive UCS instance, it could take up to three minutes for Chat Server to detect that the listening port is not open.

Setting Load Limits

Starting in the 8.5.0 release of Chat Server, you can impose load limits on Chat Server: when Chat Server reaches the specified limit, it no longer creates new sessions or restores existing sessions.

Set load limits using the following configuration options (full descriptions are in the eServices Options Reference):

  • Enable or disable the general functionality of load limitation using limits-control-enabled.
  • Set specific limits:
    • limit-for-flex-users—Maximum number of currently logged-in flex users.
    • limit-for-reply-delay— Configures the maximum average delay (in milliseconds) for processing requests. The average value is calculated on the limit-average-interval interval. This delay increases if the Chat Server instance is overloaded with a large number of incoming requests.
    • limit-for-sessions—Maximum number of concurrent chat sessions.
    • If any of these limits is reached, Chat Server stops creating and restoring sessions.

  • If Chat Server is configured in primary/backup mode (not recommended; see Deploying High-Availability Chat Server), you may want to stop it from reporting service unavailable to SCS when a limit is reached. You can do this using limits-reached-report-scs. Blocking the reports avoids a scenario in which Chat Server in primary/backup mode closes a chat session because (1) Chat Server reaches any of its configured load limits, (2) Chat Server sends a service unavailable notification to Solution Control Server, (3) SCS switches Chat Server to backup state, which closes the chat session. (This scenario does not apply if Chat Server is in N+1 mode: multiple Chat Servers with no backup configured).
  • Set the point at which Chat Server returns to full functionality using limits-restore-threshold. This value is a percentage of the limit set by the three limit-for-X options.

Example

If limit-for-flex-users is set to 400 and limits-restore-threshold is set to 80, then:

  1. When the number of flex users reaches 400, Chat Server stops creating and restoring sessions, and rejects login attempts by flex users.
  2. When the number of flex users falls to 320, Chat Server returns to full functionality.

KPI (Key Performance Indicator) counters

Starting with release 8.5.103, Chat Server includes KPI (Key Performance Indicator) counters that monitor activity within the server.

Accessing KPI counters

Access KPI counters in one of two ways:

  • The Chat Server log. by configuring options log-output-content, log-output-proviso, log-output-timeout in the [health-service] section.
  • The web REST interface which you can configure by:
    • Adding a port with the ID=health to the ports of Chat Server.
    • Adjusting the soap-* options found in the [health-service] section.

Web interface

Access the web interface through the following URL format: http://ServerName:ServerPort/Counters?<list of parameters> where:

  • ServerName is the host name where Chat Server is running.
  • ServerPort is the web service port, also specified as the health port of Chat Server.


Web interface parameters:

Name Description Valid Value Default Value
metadata Returns a list (in JSON format) of all supported counters, with descriptions. true, yes

false, no

false
content Returns a list (in JSON format) of counters according to the provided parameter value. all—returns all available counters

new—returns only recently updated counters
set —returns all initialized (non-zero) counters

all
reset Resets all counters to zero. true, yes

false, no

false

If a parameter is omitted or has an invalid value, then the default value is used for that parameter. Parameters are processed according to the following rules:

  • If reset is true, then all the counters will be reset and then the rest of the parameters will be processed.
  • If metadata is true, then the content parameter will be ignored and the metadata will be sent.

Example URLs:

  • http://hostname:7000/Counters?content=set
  • http://hostname:7000/Counters?metadata=true&reset=true

How counter values are calculated

All counters, except the process memory counter, are cumulative. The value begins to accumulate the moment the application is launched or the counters are reset. To calculate the difference, the user must use two sample counters from different times and subtract the earlier sample from the later one. To find the counter's rate value, divide the difference by the number of elapsed seconds between the two samples.

Important
On some platforms, the time for processing internal activities may be reported as zero. This does not indicate an issue with the counter. On the contrary, a rapidly growing value on the counter for internal activity indicates that the server is overloaded.

Feedback

Comment on this article:

blog comments powered by Disqus
This page was last modified on October 12, 2018, at 11:50.