This chapter describes the information you need to consider for improving the performance of Communications Express.
This section describes how to set up and configure LDAP pools and set LDAP connections to improve the efficiency of Communications Express. Some components of Communications Express require connections to the LDAP server to retrieve and manage information. The amount of time required to establish a connection and retrieve information from the LDAP server can be huge if a large number of users are logged in. You can reduce the turnaround time to establish the connection and retrieve information if a pool of LDAP connections are already created which Communications Express can use.
In a typical production environment of Communications Express, an LDAP load balancing and failover mechanism is adopted. Here, one LDAP server (known as the master) is responsible for retrieving information and another set of servers (known as the failover servers) are used in case of a catastrophe (where the master server fails). This way, a single point of failure is avoided.
Communications Express contains an LDAP failover Manager module that is responsible to retrieve connections from the master or slave servers. Each load balancing server maintains a pool of available free connections. Whenever a Communications Express component requires a connection to the LDAP server, the LDAP failover manager provides the component with a connection from the pool of LDAP connections.
To configure Communications Express to create a LDAP Failover Manager, you need to set a few parameters in the uwcauth.properties file.
Change directory to uwc-deploy-path/WEB-INF/config/.
Edit the uwcauth.properties file and set the following parameters.
ldapusersession.ldapport : Set this parameter to the port on which the LDAP server is running.
ldapusersession.ldaphost: Set this parameter to the LDAP host list of the LDAP server names. This can be a comma separated list. If the LDAP servers are running on a non-default port; this can be specified by a comma. For example, host1, host2:1290, host3, host4:2546. Here, host1 and host3 are running on the default ports, whereas host2 and host4 are running on non-default ports.
Restart the web container on which Communications Express is deployed.
In a network intensive production scenario where large amount of data is transferred, the performance can be enhanced by enabling compression of the server response. This way, data is compressed and sent across the network — thus improving the performance.
To enable compression of the server response, you should set the uwc.gzip.compression parameter in the uwcconfig.properties file.
Enable compression of the sever response in the uwcconfig.properties file, by setting the uwc.gzip compression parameter value to true.
For example, uwc.gzipcompression = true and restart the web container on which Communications Express is deployed.
When users log on to Communications Express, a session is created on the server side for that user. The session contains data about each user and is maintained on the server side. When a large number of concurrent users are logged in, managing the session data may need resources. By setting the session-timeout for a session to an optimal value and closing unused sessions that are open or inactive for a long time, the performance can be improved.
To customize the session-timeout for Communications Express, edit the web.xml file found in uwc-deploy-dir/ WEB-INF directory. This XML file contains the XML tag session-config which has the attribute session-timeout. This attribute defines the session time-out in minutes. Change the value of the session-timeout attribute to the desired value.
For example, the following defines session-time-out for 10 minutes:
<session-config> <session-timeout>10</session-timeout> </session-config>
This section describes the tuning you can perform on Directory Server to enhance performance.
To determine if these parameters are set to appropriate values, type the following command:
ldapsearch -b /base/ (&(icscalendarowned=*/user/*)(objectclass=icsCalendarUser))
/base/ is the LDAP base DN of the directory server where the user and resource data for Calendar Server is located.
/user/ is the value that an end user can enter in the Calendar Search dialog under the Subscribe option in Communications Express.
The LDAP server returns an error, if the nsSizeLimit or the nsLookthroughLimit parameter is not large enough.
Ensure that the value for nsSizeLimit parameter is large enough to return all the desired results, otherwise, data can get truncated, and no results will be displayed.
Ensure that the value for 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. By doing this, no search limit is set for nsLookthroughLimit.
It is recommended that the User or Group and Address Book entries in LDAP are setup separately.
To enhance the Web Server's performance, perform the steps described in this section.
<VS id="https-siroe.com" connections="ls1" mime="mime1"aclids="acl1" urlhosts="<webserver hostname" acceptorthreads="<noofcpus\>" \>
Add or set the following JVM options in the server.xml file of Web Server.
<JVMOPTIONS>-Xms/JVMOPTIONS> (approximate value according to the memory available)
<JVMOPTIONS>-Xmx /JVMOPTIONS>(approximate value according to the memory available)
<JVMOPTIONS>—XX: NewSize = <1/3rd of the heap allocated></JVMOPTIONS>
<JVMOPTIONS>-XXMaxNewSize =<1/3rd of the heap allocated></JVMOPTIONS>
The first option indicates Maximum heap size and the second option indicates Minimum heap size
It is recommended to have the same values for both the options.
Add the following JVM option
JVMOPTIONS -server /JVMOPTIONS
This section describes how load balancing across multiple CPU on Calendar Server can enhance performance.
If a server has multiple CPUs, by default Calendar Server distributes the HTTP Service such as cshttpd processes and Distributed Database Service such as csdwpd processes across CPUs.
The service.http.numprocesses and service.dwp.numprocesses parameters in the ics.conf file 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 eight CPUs, but you want a cshttpd and csdwpd process to run in only 4 CPUs, set the parameters as:
Add the service.loadbalancing parameter to the ics.conf file
Set service.loadbalancing to “no.”
Restart Calendar Server for the change to take effect.
For information on load balancing refer to Appendix C, Calendar Server Configuration Worksheet, in Sun Java System Calendar Server 6.3 Administration Guide in Sun Java System Calendar Server 6.3 Administration Guide