Web Services for Remote Portlets (WSRP) is a popular standard among the Digital Experience customer base.
In today's blog post I will discuss some performance Tips and Tricks around WSRP:
When considering WSRP performance tuning you need to think about both the Consumer and the Producer side. For this discussion we will assume that the Producer is running on WebSphere Application Server and the Consumer being WebSphere Portal 8.5.
The communication via WSRP happens via SOAP over http(s). So on the Producer side I recommend to monitor the web container threads and possibly increase those. The WSRP protocol also supports the usage of sessions - so the session timeout is another important setting on the Producer.
The portlet pool on the producer is refreshed periodically. The portlet pool reload interval determines the time interval after which the portlet pool is refreshed. The default value for the reload interval is 1800 seconds. I recommend to increase this value to at least half a day to lower the overhead of the reload. The setting wsrp.description.reload.interval in the producer ear file controls the reload.
Besides those the classic WAS tuning applies:
- Heap size and garbage collection settings to optimize the garbage collection
- leverage Vertical and Horizontal scaling to scale out based on parallel requests
- Class Loader cache tuning
- Application Tuning
If on Liberty some extra tunings apply – e.g. no clustering but one can still have multiple instances.
Also leverage the latest WSRP producer from the catalog for best performance. You can find it here:
On the Consumer side the classic Portal tuning would typically be applied (e.g. heap size, cache tuning, ...).
Specifically for WSRP I recommend to consider the following areas:
- Leverage the latest 8.5 cumulative fix for best performance - we have implemented multiple performance improvements in the last cumulative fixes (CFs).
- If the actual processing on Portal is relatively low since the majority of portlets is served via WSRP I recommend to increase the number of Web Container threads
(and of course the Portal datasources max connection pool setting accordingly).
- Increase com.ibm.websphere.webservices.http.maxConnection setting – it limits the amount of parallel outgoing web services calls - the default is 25 for JAX-RPC (below Portal 8.5) and 50 for JAX-WS (Portal 8.5). Check the following URL for details: http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rwbs_httptransportprop.html
- Consider a timeout setting for WSRP requests to avoid hangs on Portal. If you have slow processing WSRP producer portlets that could stop responding, setting a timeout setting on the Consumer can prevent the possibility of the slow Producer response impacting the availability / performance of the overall solution. Check the following URL for details: http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/admin-system/wsrp_config_tmeout_prop.dita
- Consider WSRP markup caching - if the data produced by the portlets can be cached. Check the following link for details: http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/admin-system/wsrpr_markup_cach.dita?lang=en
- Avoid fragment caching - portlet fragment caching does not perform as good as WSRP markup caching.
- Consider which security model is going to be used between Producer and Consumer. I have ranked the performance of the different options from Best(1.) to Worst(4.):
1. No Security
2. LTPA - cookie based security.
3. WS-Policy based Security
4. Standard Web Services WSS-WS-Security.