2.4 Performance considerationsAdded by Chander Ponnusamy on March 22, 2013 | Version 1 (Original)
The performance of IBM Connections is largely dependent on the following variables:
- The amount of memory allocated to the Java virtual machines used by WebSphere Application Server
- The number of processors available for processing
- The speed of connectivity between the application server and the database
- The speed of the underlying disk infrastructure
With this number of variables, there is no hard-and-fast rule to maximizing the performance of an IBM Connections environment. At the outset of your project, however, if you consider your system to be likely to grow in scale after successful deployment, you should consider ensuring you have the knowledge and skills to horizontally and vertically scale IBM WebSphere Application Server through its Network Deployment tools so that you can balance the load.
The Connections team prepared an excellent document for version 3 which describes the many facets of performance tuning - Click here.
In the system we built for this guide, we have split the burden of providing the communities functionality across two servers (WAS Cluster 1 and WAS Cluster 2). Activities resides on its own server and all other applications reside on the fourth server. This design was arrived at because we expect that Communities will be the most heavily-used application and splitting them provided greater resilience and greater throughput. Bookmarks, Wikis, and so on are used less and can be safely combined onto a single server.
Tuning IBM Connections server improves performance of the applications and it requires tuning various components till the desired results are achieved. The following topics give some generic performance considerations for IBM Connections server :
- Avoiding co-location
The system hosting the IBM Connections server should not have database server installed on the same server . Separating the database server to a dedicated server improves performance for IBM Connections server and can be tuned independently. There are multiple read and write operations performed on a database server and hence not to place database server on the server that host the IBM Connections.
- RDBMS server performance
IBM Connections server applications make extensive calls to database server to provide its functionality. In larger deployment scenario, consider creating a dedicated database server instance per database. The database server must have 8GB of memory in small deployment scenario and 16GB of memory in larger deployment scenario. The database storage disk should be a dedicated disk subsystem and able to handle heavy workload for read and write operations.
- LDAP performance and directory size
IBM Connections server caches the user information locally in the respective database. The profile application extensively uses LDAP server to retrieve user information through Tivoli Directory Integrator (TDI) and stored locally in the profiles database. By indexing the LDAP server search filter attribute and login attribute helps faster lookup and improves the performance of IBM Connections server. Any search taking more than 100 milliseconds need to be corrected.
- 64-bit architecture for WebSphere, TDI, and RDBMS
IBM Connections server 4.0 supports only 64-bit architecture. 64- bit architecture gives better performance through more effectively using the process power of the system. . Setting large heap size is possible in the 64- bit systems, which provide more inflight transactions and higher throughput. A general recommendation is to use 64- bit system for WebSphere, TDI and RDBMS for better performance.
- Placing IHS on a separate server
IBM HTTP Server is the entry point for all IBM Connections applications and must be placed on the separate server. Configuring Files and Wikis applications data directories accessible by web server helps performance improvement and the request is served from the web server itself instead of WebSphere Application Server. This off loads the traffic going to WebSphere Application Server and improves the overall performance of the applications.
- Identifying heavy-use applications
In a large deployment scenario, IBM Connections applications are installed into dedicated application server cluster. Depending upon the usage of application, additional node can be added into the application cluster for that application to provide better performance results.
- Monitoring disk space usage
In a large deployment scenario, IBM Connections applications are installed into multiple nodes with a dedicated application cluster. Additional nodes can be added to the application cluster to provide scalability and high throughput. Monitor the disk space usage of IBM Connections server nodes, shared content store, temporary directory, and log directory locations to ensure that there is sufficient disk space or current operations and plan for future growth.
- Dedicated resources
IBM Connections 4.0 provides metrics application to utilize the analytic capabilities of Cognos Business Intelligence (BI) server. IBM Cognos BI server and database server should be installed on a dedicated server. IBM Cognos server must be federated into IBM Connections server deployment manager to enable Single Sign on (SSO) features. We recommend to use the same IBM HTTP Server as IBM Connections application.
- Networking routing for IBM Connections requests
IBM Connections applications serve mainly static content, Java script, and images. In a large deployment scenario, we recommend to cache the content of the applications. . IBM WebSphere Edge component proxy caches the content and improves the client-side performance. By using reverse caching proxy of IBM WebSphere Edge component, the workload is reduced on the server and improves the server-side performance.
The heap size of the JVM should be less than the physical memory of the system and larger heap size is required for cluster setup when memory-to-memory replication is enabled. We recommend to set minimum and maximum heap size as same to avoid heap fragmentation. For small and medium deployment, the recommended heap size would be 2506 MB. For the large deployment, the recommended heap size is as follows.
Max Heap Value