Chapter 21 Tuning Calender Server Performance

To improve the performance of Sun Java™ System 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 and mailAlternateAddress specify a user’s primary and alternate email addresses. See also To Add the Required mail Attribute and To Set Up Email Aliases.



Note	If you run the Directory Server Setup (comm_dssetup.pl) script to configure Directory Server 5.x, the script adds these and other indexes. See Chapter 2, "Directory Preparation Script (comm_dssetup.pl)".

For information about adding directory server indexes, refer to the Directory Server Configuration, Command, and File Reference on the following website:

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.

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:

To Improve Search Performance by Indexing


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 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 the Calendar Express Subscribe->Calendar Search dialog.

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 the Directory Server Configuration, Command, and File Reference on the following website:

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

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 LDAP data cache by editing the ics.conf file as follows:

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

The LDAP data cache is enabled by default. To tune it using the ics.conf parameters, adjust one or more of the parameters found in Table 21-1.

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

Table 21-2 ics.conf Parameters for Configuring the LDAP SDK Cache
Parameter	Description and Default Value
service.ldapmemcachettl	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 diskspace. To help manage the amount of disk space your archival and hotbackups 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 diskspace 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 hotbackup:

Calendar Server keeps backups for the maximum number of days possible without going over the threshold on diskspace. 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 diskspace 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 diskspace usage falls below the threshold.

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

Table 21-3 lists the ics.conf parameters that control the diskspace 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 hotbackups held on disk.
caldb.berkeleydb.hotbackup.maxdays	6	Maximum number of days of hotbackups held on disk.
caldb.berkeleydb.hotbackup.threshold	70	Percent of diskspace used for hotbackups. 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 diskspace used for archival backups. Triggers purge of oldest copies when exceeded.

Using a Memory-Based File System for the Session Database

To improve performance, you can configure a memory-based file system (tmpfs) for the session database by setting the following parameter in the ics.conf file:

The tmpfs file system is then overlaid based on the values of the service.http.sessiondir.path and service.admin.sessiondir.path parameters.

For more information, see the tmpfs(7FS) and mount_tmpfs(1M) man pages in the Solaris documentation:

Using Load Balancing Across Multiple CPUs

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

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 CPUs for the server during installation, but you can reset these values. For example, if a server has 8 CPUs, but you want a cshttpd and csdwpd process to run in only 4 CPUs, set the parameters as:

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.

Timeout Values for csadmind

Table 21-4 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

Table 21-5 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:

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.

Tuning the Calendar Express User Interface

This section contains instructions for tuning Calendar Express in the following ways:

Using the Refresh View Option

For Calendar Express end users, the Refresh View option improves performance by using calendar data in the browser cache to refresh a view rather than requiring an update from the Calendar Server database.

To enable the Refresh View option, the following parameter in the ics.conf file must be set to “yes”:

If you reset this parameter, you must stop and then restart Calendar Server for the new value to take effect.

When the Refresh View option is configured for a site, Calendar Express displays Refresh View on all calendar views on the View tab.

When a user clicks Refresh View, Calendar Express first checks whether the calendar data in the view has changed before requesting an update from the calendar database. If the data has not changed, Calendar Express uses information in the browser cache to refresh the view. Unnecessary requests to the calendar database are avoided, which is especially useful if a calendar has a large number of events or tasks.

If an event or task has changed, Calendar Express requests an update from the calendar database to refresh the view. Thus, users can also use Refresh View to ensure that Calendar Express always displays the latest calendar data.

Disabling the Tool Bar Repainting Option

The tool bar repainting option causes a Calendar Express view to be repainted (refreshed) when a user clicks refresh. Sometimes, however, this option can cause performance problems because Calendar Server refreshes a view by performing XML and XSLT transformation for the tool bar.

To disable the tool bar repainting option, set the following parameter in the ics.conf file to “no”:

If ui.toolbar.repainting.enable is set to “no”, clicking refresh on any view takes the Calendar Express user back to the default view.

Setting ui.toolbar.repainting.enable to “no” can improve performance, because Calendar Express does not perform the XML and XSLT transformation for the tool bar.

If the browser cache option (browser.cache.enable parameter) is set to “yes”, the tool bar repainting option is not used.

XSL Rendering in the Client Browser

Calendar Server performs client-side rendering by downloading the XSLT processing to the end user’s browser, which in turn reduces the processing that must be done by Calendar Server. Calendar Server downloads the XSLT processing only if the browser is capable of rendering the XSLT processing. In the current release, this applies only to Internet Explorer 6.0.

Tests have shown that client-side rendering can improve the interface (UI) scalability by 4 to 6 times, which means that Calendar Server can support 4 to 6 times as many concurrent end users without significantly degrading performance of the CPU.

The following parameter in the ics.conf file controls client-side rendering (currently for Internet Explorer 6.0 or later only):

By default this parameter is set to “yes”. To turn off client-side rendering, set the parameter to “no” and then restart Calender Server.

Previous Contents Index Next
Sun Java System Calendar Server 6 2005Q1 Administration Guide