Calendar Server performance can be adjusted using timeout values for various ics.conf parameters.
The following types of timeouts exist:
For information about editing ics.conf parameters, see Editing the ics.conf Configuration File.
The following table describes the Calendar Server timeout parameters in the ics.conf file used by the Administration (csadmin) service.
Table 21–4 HTTP Timeout Values for the Administration Service (csadmin)
Parameter |
Description |
---|---|
service.admin.idletimeout |
Specifies the number of seconds the csadmind service waits before timing out an idle HTTP connection. The default is 120 seconds (2 minutes). |
service.admin.resourcetimeout |
Specifies the number of seconds the csadmind service waits before timing out an HTTP session for a resource calendar. The default is 900 seconds (15 minutes). |
service.admin.sessiontimeout |
Specifies the number of seconds the csadmind service waits before timing out an HTTP session. The default is 1800 seconds (30 minutes). |
The following table describes the Calendar Server HTTP timeout parameters in the ics.conf file that apply to end users.
Table 21–5 HTTP Timeout Values in ics.conf for End Users (cshttpd Service)
Parameter |
Description |
---|---|
service.http.idletimeout |
Specifies the number of seconds the cshttpd service waits before timing out an idle HTTP connection. The default is "120" seconds (2 minutes). |
service.http.resourcetimeout |
Specifies the number of seconds the cshttpd service waits before timing out an HTTP session for a resource calendar. The default is "900" seconds (15 minutes). |
service.http.sessiontimeout |
Specifies the number of seconds the cshttpd service waits before timing out an HTTP session. The default is "1800" seconds (30 minutes). |
The following ics.conf file parameter specifies the time in seconds to wait before Calendar Server scans the Group Scheduling Engine (GSE) queue for incoming jobs:
gse.belowthresholdtimeout="3"
If there are more jobs in the queue than the maximum threads allocated, the last thread always scans the queue again. Therefore, this setting only takes effect when the number of jobs is below the maximum threads allocated.
The default is "3". Increasing this number reduces the frequency the server scans the queue and can improve overall performance. However, if the queue is getting too large because of an increased volume of events, the time can be decreased to allow the queue to be processed faster. This may serve to slow down overall performance, but events will be updated sooner.