Sun Java System Calendar Server 6 2005Q4 Administration Guide

Chapter 21 Tuning Calendar Server Performance

To improve the performance of Calendar Server, consider the following options:

Indexing the LDAP Directory Server

To improve performance when Calendar Server accesses the LDAP directory server, add indexes to the LDAP configuration file for the following attributes.

icsCalendar: This attribute is used to search for the default calendar for a calendar user or resource. Specify presence (pres), equality (eq), and substring (sub) index types.
icsCalendarOwned: This attribute is used to search for other calendars owned by the user. Specify presence (pres), equality (eq), and substring (sub) index types. See also Improving Calendar Search Performance in a DWP Environment.
mail, mailAlternateAddress: These attributes specify a user’s primary and alternate email addresses. See also Creating Users and Resources and Calendar Server Utilities (csuser enable).

For information about adding directory server indexes, refer to Directory Server documentation found at:

http://docs.sun.com/coll/1316.1

Improving Calendar Search Performance in a DWP Environment

When you are in a DWP environment, that is, the calendar database is distributed across multiple back-end servers, searching for a calendar in the calendar database can be time consuming. It can be faster to look in the LDAP entry first and find out directly which DWP host the calendar resides on.

This section contains the following topics:

To Enable Calendar Searches to Look at LDAP

To enable calendar searches to look at the LDAP directory first, and the calendar database second, perform the following steps:

Edit the service.calendarsearch.ldap parameter in the ics.conf file, setting the parameter to “yes”, which is the default, as shown below:

service.calendarsearch.ldap="yes"

Restart Calendar Services as follows:

start-cal

Note –
If you are allowing anonymous access to public calendars, you might prefer to disable calendar searches from looking at LDAP. In fact, Communications Express expects the parameter value to be “no”.

To Improve Search Performance by Indexing

To determine if the calendar search performance can be improved by indexing, try the following LDAP command:
ldapsearch -b "base" "(&(icscalendarowned=*user*) (objectclass=icsCalendarUser))"
where base is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located, and user is the value that an end user can enter in a search dialog in .

Tests have shown that with 60,000 entries, the above search took about 50-55 seconds without indexing icsCalendarOwned. After indexing, the above search took only about 1-2 seconds.

Index appropriate LDAP attributes, or at least, icsCalendarOwned, by running comm_dssetup.pl.

The comm_dssetup.pl, indexes this attribute and many others to improve performance in various ways. If you have not run comm_dssetup.pl, or ran it but did not perform the indexing, you can run the utility again to do the indexing, or you can use Directory Server tools to perform the indexing.

For information on how comm_dssetup.pl does indexing, see Attribute Indexes.

For information about adding directory server indexes, refer to Directory Server documentation found at:

http://docs.sun.com/coll/1316.1

Improving Performance of Calendar Searching by Disabling Wildcard Searches

By default, wildcard searches are disabled in Calendar Server. That is, when you search for a calendar using the graphical user interface, or when you issue search_calprops.wcap in your custom interface, it searches for an exact match to the search string passed in with the WCAP command.

If you have enabled wildcard searches by uncommenting the following line in the ics.conf file (by removing the exclamation point (“!”) at the beginning), you may be experiencing a negative impact on performance.

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

To test the impact of wildcard searches on performance, comment out the line again by inserting the exclamation point (“!”) in front of it.

Improving Performance of the CLD Plug-in

Before the system accesses a calendar from the calendar database, it must determine which back-end machine stores that user’s calendars. To find the appropriate back-end machine, the system searches the LDAP directory for the user’s entry and picks up the icsDWPHost attribute. This search is time consuming, and it must be performed for every access to the calendar data. Every user session can result in many accesses of the database and thus many searches of the LDAP. To save time and enhance performance, enable the CLD cache by editing the ics.conf file as follows:

caldb.cld.cache.enable="yes"

The LDAP data cache stores the user ID and its associated icsDWPHost attribute. Before searching the LDAP for a user’s entry, the system checks the cache for the user’s ID. If it is in the cache, it picks up the back-end host name from the icsDWPHost attribute stored there. If it is not in the cache, the system performs the LDAP search and copies the user ID and attribute into the CLD cache. Subsequently, accesses to the user’s calendar data will be faster, since it will now find the user ID in the cache.

Improving Performance of the LDAP Data Cache

With the LDAP data cache enabled, you can tune it using the ics.conf parameters, adjust one or more of the parameters found in the following table:

Note –

The LDAP data cache is enabled by default. You can disable it by setting: local.ldap.cache.enable="no"

Table 21–1 ics.conf Parameters Used to Customize LDAP Data Caching


Parameter	Description/Value
`local.ldap.cache` `.checkpointinterval`	The number of seconds for the checkpoint thread to sleep between checkpoints. The default is `“60”`. In a high activity LDAP, you might want to decrease the interval to keep the cache as current as possible. At the same time, remember that the more often you refresh the cache, the more system overhead you introduce.
`local.ldap.cache.` `circularlogging`	Specifies whether to remove the LDAP data cache database log files after they have been processed. The default is `“yes”`. Do not change this parameter unless you have a custom clean up routine that will remove the old log files.
`local.ldap.cache.` `logfilesizemb`	Specifies the maximum size in megabytes of checkpoint file. The default is `"10”` megabytes. If you have a high activity LDAP, this file could fill up before the checkpoint interval is over. Try to set the value to a number that is close to the actual size of the logs according to your experience
`local.ldap.cache.` `maxthreads`	Specifies the maximum number of threads for the LDAP data cache database. The default is `“1000”`. In a high activity LDAP, you might want to increase the number of threads. This could cause increased CPU utilization. Decrease the number of threads only if your LDAP activity is minimal.
`local.ldap.cache.` `mempoolsizemb`	Specifies the number of megabytes of shared memory. The default is `“4”` megabytes.
`local.ldap.cache.` `entryttl`	Specifies the “time to live” (TTL) in seconds for an LDAP data cache entry. The default is `“3600”` seconds (1 hour). If your cache is filling up too fast (high activity), you can decrease the TTL time. However, this could increase the overall number of LDAP database accesses, which could slow the system down overall.
`local.ldap.cache.` `cleanup.interval`	Specifies the interval in seconds between each cache database cleanup. The default is `“1800”` seconds (30 minutes). The system removes expired entries. The time interval does not have to be the same as the entry TTL time. But synchronizing them can make it more efficient.
`local.ldap.cache.` `stat.enable`	Specifies whether or not to log the access to the LDAP data cache and to print statistics in the log file. The default is `“no”`. For performance enhancement, use this only in debug mode.
`local.ldap.cache.` `stat.interval`	Specifies the interval in seconds when each statistics report is written to the log file. The default is `“1800”` seconds (30 minutes). This is only active if local.ldap.cache.stat.enable is enabled. Decreasing the interval can help you pinpoint problems. Increasing the interval helps decrease system load.

Note –

Communications Express expects data caching to be disabled.

Tuning the LDAP SDK Cache

There are a couple of parameters that control how long an item stays in the cache, and how large the cache can be.

To tune the cache, edit one or more of the parameters as shown in the following table:

Table 21–2 ics.conf Parameters for Configuring the LDAP SDK Cache


Parameter	Description and Default Value
`service.ldapmemcachettl`	This is not currently implemented. You must manually remove the contents of the `ldap_cache` directory and then restart Calendar Server. If `service.ldapmemcache` is `"yes"`, this parameter is used to set the maximum number of seconds that an item can be cached. If `“0”`, there is no limit to the amount of time that an item can be cached. The default is `“30”`.
`service.ldapmemcachesize`	If `service.ldapmemcache` is `"yes"`, this parameter is used to set the maximum amount of memory in bytes that the cache will consume. If `“0”`, the cache has no size limit. The default is `“131072”`.

Tuning Automatic Backups

You must balance the number of backups you keep on disk with the need to not exceed available disk space. To help manage the amount of disk space your archival and hot backups take, you can change the settings of various ics.conf parameters that determine how many copies of the backups you keep at one time and where the disk space threshold is that will trigger clean up of the older copies.

There are three types of parameters that can be adjusted for the each backup type, archival and hot backup:

mindays – The minimum number of days worth of backups held on disk.
maxdays – The maximum number of days worth of backups held on disk.
threshold – The percentage of disk space used. This is used as a trigger point.

Calendar Server keeps backups for the maximum number of days possible without going over the threshold on disk space. So if the current backup is going to push the disk usage above the threshold, the system will purge the oldest backup copy and see if disk space usage goes below the threshold. It will continue to purge old backup copies until either of the following conditions is met: removing another backup copy would bring the number of backups on disk below the minimum number of backup copies, or the disk space usage falls below the threshold.

Therefore, you can manage the amount of disk space backups use with the threshold parameter. And conversely, you can manage how many backups you keep on disk by adjusting the amount of disk space and copies allowed.

The following table lists the ics.conf parameters that control the disk space and number of backups kept on disk:

Table 21–3 ics.conf Parameters Used to Set Number of Backups Held on Disk


ics.conf Parameter	Default Setting	Description
`caldb.berkeleydb.hotbackup.mindays`	3	Minimum number of days of hot backups held on disk.
`caldb.berkeleydb.hotbackup.maxdays`	6	Maximum number of days of hot backups held on disk.
`caldb.berkeleydb.hotbackup.threshold`	70	Percent of disk space used for hot backups. Triggers purge of oldest copies when exceeded.
`caldb.berkeleydb.archive.mindays`	3	Minimum number of days of archival backups held on disk.
`caldb.berkeleydb.archive.maxdays`	6	Maximum number of days of archival backups held on disk.
`caldb.berkeleydb.archive.threshold`	70	Percent of disk space used for archival backups. Triggers purge of oldest copies when exceeded.

Using Load Balancing Across Multiple CPU's

If a server has multiple CPU's, by default Calendar Server distributes the HTTP Service (cshttpd processes) and Distributed Database Service (csdwpd processes) across the CPU's.

The service.http.numprocesses and service.dwp.numprocesses parameters determine the actual number of processes that run for each service. By default, these parameters are set to the number of CPU's for the server during installation, but you can reset these values. For example, if a server has 8 CPU's, but you want a cshttpd and csdwpd process to run in only 4 CPU's, set the parameters as:

service.http.numprocesses="4"
 service.dwp.numprocesses="4"

To disable load balancing, add the service.loadbalancing parameter to the ics.conf file and set it to “no”. Then restart Calendar Server for the change to take effect.

Using Timeout Values

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.

Timeout Values for csadmind

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).

HTTP Timeout Values for End Users

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).

GSE Queue Timeout Value

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.