It would be too hard explaining all configuration details about tuning the performance on a WebSphere Portal Server (WPS) as these rely heavily on the chosen infrastructure. I will however provide a nice troubleshooting guide that allows you to track down the performance bottlenecks on your WebSphere Portal environment.
IBM WebSphere Portal software provides an enterprise SOA based solution to build core portal services that aggregate applications and content as role-based applications.
When starting with performance tuning, it is important to begin with a baseline, monitor the performance metrics to determine if any parameters should be changed and monitor the performance metrics again to determine the effectiveness of the change.
In short, you need to measure, measure… and then just measure once again.
What do you need to do in order to start performance tuning on WebSphere Portal?
* Review the hardware and software requirements for your system
* Install the most current fix pack of WebSphere and Portal
* Review the design and architecture of the installed applications
o Hunt for memory leaks and expensive operations like the creation of connections
* Make sure that you use the latest JDBC driver (type 4) available for your database
What can you do to determine the right values for your environment?
* Measure system performance and collect performance data
o Check to determine if any systems have high CPU, network or disk utilization
o Check for uneven loading across cluster members
o Ensure that some external device does not limit your system
o Excessive garbage collection can limit throughput
* Locate the bottleneck
o A thread dump might reveal a bottleneck at a synchronized method
o Make sure enough threads are available to process the work
o But too many threads can increase resource contention and reduce throughput
* Start tuning your system
Most performance issues that I’ve encountered with Portal installations were about incorrectly configured Java Virtual Machine settings, inefficient data source/connection pooling configurations or related to a bad application design or architecture.
I’ll give you some general recommendations of tuning parameters you can use for WebSphere Portal on a Windows environment.
Java Virtual Machine settings
The recommendations apply to systems that have more than 2 GB of native memory. You can set the initial heap to the size of the maximum when using the Gencon GC policy in IBM JDK
* Initial heap size: 768 MB
* Maximum heap size: 1280 MB
Note that Windows limits the memory size of its processes to 2 GB each on 32bit systems. WPS on Solaris uses the Sun JDK instead of the IBM JDK that needs some extra tuning on these systems.
Web container settings
Reducing the default value of 30 to the proposed value can help reduce memory consumption requirements, allowing a higher user load to be sustained for a longer period of time.
* Session timeout: 10 minutes
* Web containers thread pool size: 50
You can further increase the value of the thread pool, if the users have to wait on available threads
Data source settings
It is best to use a separate data source for each WebSphere Portal database.
We just scratched the surface here, as there is a whole lot more of tuning possibilities on WebSphere Portal like configuring the Portal services (personalization, like minds, cache manager), tuning operating system settings, tuning the database and LDAP server access, web server configuration, portal caches, fine-tuning the Web 2.0 theme, and a whole lot more.
I know this guide isn’t complete at all, but it will get you started. If you really need more information on this topic, the WebSphere Portal 6.1 Info Center will provide you with a whole bunch of information.
But really, tune the JVM to the right size and check the deployed applications on memory leaks and 80% of the performance issues can be tackled with just that!