Tuning the Thread Pools

To configure the number of allowed threads used by the Portlet Worker thread manager, change the value of org.jasig.portal.portlet.worker.threadPool.maxThreads in uportal-war/src/main/resources/properties/portal.properties. 

For example, to configure the thread pool to a maximum of 150 threads:

org.jasig.portal.portlet.worker.threadPool.maxThreads=150

When an HTTP request for a uPortal page is made, each portlet on the page is queued up in a shared pool of Portlet Worker threads that are shared by all users accessing uPortal.  If you have a large number of portlets on your page, especially if you have servers with adequate computing and threading resources to handle larger numbers of Portlet Worker threads, you will get better user response time especially during periods of heavy traffic if you increase the number of Portlet Worker threads.  When you have too few worker threads, page responses are delayed because uPortal is waiting to be able to execute and get responses from portlets on a page.  When you have too many worker threads, it could lead to longer response times due to CPU starvation (high CPU usage) or context thrashing (high CPU times or simply longer response times because more time is spent switching context between threads and less time getting actual work done).

A good way to determine if your installation with your hardware would benefit from increasing the number of Portlet Worker threads is to compare the average response time for both a normal usage and heavy usage load test with varying number of Portlet Worker threads.  You want to find the 'sweet spot' in a continuous high-load situation where the CPU is not overtaxed and the page response times are minimized.

Some universities doing performance testing have found that they can improve their uPortal page response time especially in a high-traffic situation by increasing the number of Apache httpd HTTP threads, the number of Tomcat connector threads, and the number of Portlet worker threads. This will typically be an n-n-x situation where Apache and Tomcat have the same number of threads to handle n number of simultaneous connections, and uPortal's worker threads will be set to x where x > n since a single uPortal page request will require a number of portlet worker threads to complete to generate the page.

If you increase the number of httpd and Tomcat threads, you may often find that you will also need to increase the number of DB connections uPortal makes to the database to keep from having increased page response times due to DB connection contention.

Having problems with these instructions?

Please send us feedback at uportal-user@lists.ja-sig.org