|
| |
| Sun Java System Calendar Server Administration Guide | |
Chapter 19
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 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 Improving Calendar Search Performance in a DWP Environment.
- mail and mailAlternateAddress specify a user’s primary and alternate email addresses. See also Required mail Attribute and Email Alias (mailalternateaddress Attribute).
Note If you run the Directory Server Setup (comm_dssetup.pl) script to configure Directory Server 5.x, the script adds indexes for the icsCalendar and icsCalendarOwned attributes.
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/db/coll/S1_ipDirectoryServer_51
Improving Calendar Search Performance in a DWP EnvironmentWhen you have your calendar database on multiple back-end servers, that is, when you are in a DWP environment, searching for a calendar 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 the LDAP directory first, and the calendar database second, be sure the following parameter in the ics.conf file is set as shown, which is the default:
service.calendarsearch.ldap = "yes"
If you are enabling calendar searches of the LDAP directory, you can improve performance of the search by:
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 Directory Server, index the icsCalendarOwned attribute using the following command on Solaris Operating Systems:
server5/bin/slapd db2index -D slapd-serverID
-t icsCalendarOwned: eq,pres,sub:2.16.840.1.113730.3.3.2.11.1where slapd-serverID is the full path to the slapd-serverID directory.
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))"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.
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.
Enabling the CLD Cache Option
To optimize searching the LDAP, set the CLD cache option as shown (“yes” is default):
caldb.cld.cache.enable = “yes”
See also, Using the CLD Cache Option.
Using the LDAP Data Cache OptionThe LDAP data cache option ensures that LDAP data is available immediately after it has been committed, even if the LDAP directory server is configured to include 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.
This section covers the following topics:
Considerations for Using the LDAP Data Cache
Use these guidelines to determine if your site should configure the LDAP data cache:
- If Calendar Server at your site accesses your master (or root) LDAP directory server directly with no delays in the availability of committed LDAP data, you don’t need to configure the LDAP data cache. Make sure that the local.ldap.cache.enable parameter is set to “no” (which is the default).
- 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, configure the LDAP data cache to ensure that your end users have the most recent data.
Master/Slave LDAP Configuration
A Master/Slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:
- If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you don’t need to configure the LDAP data cache.
- If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written transparently via an LDAP referral to the master directory server, which in turn replicates the data back to each slave directory server.
In this second type of configuration, problems with inaccurate LDAP data can occur because of the delay in the availability of committed LDAP data to the slave directory servers.
For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.
If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.
Table 0-1 lists the LDAP attributes that are affected by a delay in a master/slave LDAP server configuration where Calendar Server accesses the master LDAP directory server through a slave LDAP directory server.
To insure that your end uses have the most recent LDAP data, configure the LDAP data cache as described in the following sections: LDAP Data Cache and LDAP Data Cache Configuration Parameters.
LDAP Data Cache
The LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.
If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the cal_svr_base/var/opt/SUNWics5/csdb/ldap_cache directory, but you can configure a different location if you prefer.
When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database. This data retrieval applies to the following operations for a single user:
Thus, the LDAP data cache database provides for:
- Data consistency across processes on a single system–The database is available to all Calendar Server processes on a multi-processor system.
- Data persistence across user sessions–The database is permanent and does not require refreshing. You can configure the time to live (TTL) for an LDAP data cache entry and the interval between each database cleanup. See LDAP Data Cache Configuration Parameters for more information.
Limitations
The LDAP data cache does not provide for:
- Reading the cache for searches where a list of entries is expected. For example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.
- Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.
- The capability to handle a user who doesn’t always log into the same server. Such a user will generate different LDAP data in the cache on each server.
LDAP Data Cache Configuration Parameters
Table 0-2 describes the configuration parameters in the ics.conf file for the LDAP data cache.
Using the CLD Cache OptionIf you are using the with the CLD plug-in, make sure the following configuration parameter in the ics.conf are set to “yes” (which is the default value for each parameter):
caldb.cld.cache.enable = "yes"
This parameter 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.
The other CLD cache option parameters you may want to set are:
For more information on these and other related ics.conf parameters, see Appendix E, "Calendar Server Configuration Parameters."
Using a Memory-Based File System for the Session DatabaseTo improve performance on Solaris Operating Systems, 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 19-1 describes the Calendar Server timeout parameters in the ics.conf file used by the Administration (csadmin) service.
HTTP Timeout Values for End Users
Table 19-2 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.
Using the Refresh View OptionFor 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 Calendar Express Tool Bar Repainting OptionThe 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 BrowserCalendar 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.