TEP workspace slow to load.

Body

TEPS workspace slow to load.

There has been a  report recently of a Tivoli Enterprise Portal Server (TEPS) workspace that was slow to load.  

The TEP client used, had started at a good speed but one particular workspace took about 5 minutes to load.

There can be a number of reasons for the data to take time load, here I will go through the steps taken to define the issue.

The first area to look at is the java heap for the TEP client; refer to this page of the manual:

http://www.ibm.com/support/knowledgecenter/SSTFXA_6.3.0/com.ibm.itm.doc_6.3/trouble/tep_31t_trouble.htm

which will take you through increasing the heap size.

 
For many situations this is enough to improve the speed, it did improve a little for this customer but not enough.

The next step was to check whether the problem was with obtaining the data,  so the TEPS tracing set of:

KBB_RAS1=ERROR (UNIT:CTSQL IN ER ) (UNIT:CTData IN ER)

 The query was run and the cq logs collected.

Support then checked the logs for the return speed of the query and it was found to be returning the full query in under 5 seconds.
 
A query can be delayed due to a number of factors that include:

1) An agent not responding to the request. The select is not returned until all agents have responded. If you have a request going to a number of agents, a good defining step is to reduce the query to run on each agent in turn, to see if one is much slower than the others.

2) One particular view on the workspace is taking longer to load, removing a view at a time and checking the response time can define the issue down to one view.

3) The amount of data collected is too large, check you what you have set for KFW_REPORT_ROW_LIMIT in the TEPS configuration.

You can set this variable to limit the number of rows returned for a report request.

A KFWITM574W warning message displays in the view indicating the result set was truncated. Set to 0 to disable.

This variable affects only report requests when the user selects the "return all rows" option on the View Properties window.

note that: KFW_REPORT_ROW_LIMIT change only applies if the Query Source is set to User defined and there are Managed System Lists in the target.

The KFW_REPORT_ROW_LIMIT must be equal or more than the total number of agents in the MSLs for each query defined in TEPS.

If query source is System defined, that environment variable has no effect at all.

4) There is a performance issue with the HUB TEMS, this will be reflected in the return speed and can be investigated further by Support.

However in this case there was no issue in the time the data was collected in so the next step was to review the TEP client machine.

Make sure any TEP client has enough memory and processing power, and the CPU is not being taken by other processes.
Check how the CPU is used at the time the workspace is loaded, in this case the CPU went to 100% while the workspace was loading and then it fell away when the workspace was loaded, so this was not the issue.

The Java version was then checked and found to be Java 7. For the version of ITM that was being run this was low a version of java and it was updated to Oracle Java 8 (64 bit).

This 64 bit version allows the max heap to be increased to the level of:

initial-heap-size="1024m" max-heap-size="2048m"

Moving to Java 8 and then the increase of the heapsize again helped to increase the speed of the workspace load.
 

However this upgrade has to be done carefully as there can be issues seen with Oracle Java 8

The following Tech Note gives what versions are supported on which version of ITM:

https://www.ibm.com/support/pages/master-list-itm-tepjava-issues

(Master list of ITM TEP/Java issues)

Make sure this is tested on one machine before rolling out to others , also make sure you do not have any other versions of Oracle java on the machine when testing.

Subscribe and follow us for all the latest information directly on your social feeds: