Appendix C Calender Server Performance Tuning

To improve the performance of Sun ONE 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 attribute is used for searching for the default calendar for a calendar user or resource. Specify presence (pres), equality (eq), and substring (sub) index types.

icsCalendarOwned is used for searching for a subscribe operation when the LDAP CLD plug-in is enabled. Specify presence (pres), equality (eq), and substring (sub) index types. See also "Using Calendar Searches of the LDAP Directory Server".

mail and mailAlternateAddress specify a user’s primary and alternate email addresses. See also "Required LDAP mail Attribute for Calendar Server Users" and "Email Alias (mailalternateaddress Attribute)".

Note If you run the Directory Server Setup (comm_dssetup.pl) script to configure Sun ONE Directory Server 5.x, the script adds indexes for the icsCalendar and icsCalendarOwned attributes.

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

Using Calendar Searches of the LDAP Directory Server

Calendar searches of the LDAP directory server are enabled by the following parameter in the ics.conf file:

If you are using calendar searches of the LDAP directory, you can improve performance by:

Indexing the icsCalendarOwned Attribute

Setting the nsSizeLimit and nsLookthroughLimit Parameters

Indexing the icsCalendarOwned Attribute

To determine if the calendar search performance of the LDAP directory server can be improved, 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.

On Sun ONE Directory Server, index the icsCalendarOwned attribute using the following command on Solaris Systems:

server5/bin/slapd db2index -D slapd-serverID
-t icsCalendarOwned: eq,pres,sub:2.16.840.1.113730.3.3.2.11.1

Setting the nsSizeLimit and nsLookthroughLimit Parameters

The nsSizeLimit and nsLookthroughLimit parameters in your LDAP directory server configuration must be large enough so that searches complete properly.

To determine if these parameters are set to appropriate values, try the following command:

ldapsearch -b "base"
"(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

If the LDAP server returns an error, the nsSizeLimit or the nsLookthroughLimit parameter might not be large enough. Follow these guidelines to set these parameters:

Ensure that the value for the nsSizeLimit parameter is large enough to return all the desired results; otherwise, truncation can occur, and no results will be displayed.

Ensure that the value for the nsLookthroughLimit parameter is large enough to complete a search of all the users and resources in the LDAP directory. If possible set nsLookthroughLimit to -1, which causes no limit to be used.

Using the LDAP Data Cache Option

The LDAP data cache option ensures that LDAP data is available immediately after it has been committed, even there is a delay in the availability of committed data.

For example, if your site has deployed a master/slave LDAP configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, the LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data.

Using the CLD Cache Option

If you are using the with the LDAP CLD plug-in, make sure the following configuration parameters in the ics.conf are set to “yes” (which is the default value for each parameter):

caldb.cld.cache.enable enables the CLD cache option. This cache stores the DWP host server information (icsDWPHost LDAP attribute) for calendar users and thus reduces calls to the LDAP directory server.

service.calendarsearch.ldap specifies that calendar searches are performed using the LDAP CLD plug-in or a user preference plug-in.

Using a Memory-Based File System for the Session Database

To improve performance on Solaris systems, 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.

Setting the gse.belowthresholdtimeout Parameter

The following parameter in the ics.conf file 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 scan the queue again. Therefore, this setting only takes effect only 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.

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 Calendar Express 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 maxing out a 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.