Sun Java System Calendar Server 6 2005Q1 Administration Guide |
Chapter 21
Tuning Calender Server PerformanceTo improve the performance of Sun Java System Calendar Server, consider the following options:
Indexing the LDAP Directory ServerTo 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:
http://docs.sun.com/coll/DirectoryServer_05q1
Improving Calendar Search Performance in a DWP EnvironmentWhen 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:
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 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:
Improving Performance of Calendar Searching by Disabling Wildcard SearchesBy 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-inBefore 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:
local.ldap.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 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 CacheThe 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.
Tuning the LDAP SDK CacheThere 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 Table 21-2:
Tuning Automatic BackupsYou 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:
Using a Memory-Based File System for the Session DatabaseTo 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:
local.instance.use.tmpfs to "true"
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:
http://docs.sun.com/db/prod/solaris
Using Load Balancing Across Multiple CPUsIf 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:
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 ValuesCalendar 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
Table 21-4 describes the Calendar Server timeout parameters in the ics.conf file used by the Administration (csadmin) service.
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.
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.
Tuning the Calendar Express User InterfaceThis 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”:
browser.cache.enable = "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”:
ui.toolbar.repainting.enable="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):
render.xslonclient.enable="yes"
By default this parameter is set to “yes”. To turn off client-side rendering, set the parameter to “no” and then restart Calender Server.