© Copyright International Business Machines Corporation 2000, 2007. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
In order to make use of SSL security when Importing performance data from TMTP, you need to set up the workbench to point to the appropriate keystore and truststore files.
If you have generated your own truststore and keystore for use with TMTP, then use those files in what follows. Otherwise, use the default agent.jks file that ships with the TMTP Management Agent (this is typically located in C:\Program Files\ibm\tivoli\MA\config\keyfiles on Windows).
Copy the agent.jks file from a machine with the Management Agent install. On the machine where your workbench is installed, create a security subdirectory in the toolkit install directory. Put a copy of the agent.jks file in the new security directory.
Then, edit the file rationalsdp.ini, located in toolkit install directory. Add the following two lines:
VMArgs=-Djavax.net.ssl.trustStore=d:\myrpainstall\security\agent.jks
VMArgs=-Djavax.net.ssl.keyStore=d:\myrpainstall\security\agent.jksNote: If the d:\myrpainstall path contains a space, use quotes around the path and file name; for example:
...trustStore="c:\Program Files\IBM\Rational\SDP\rpa\security\agent.jks"Restart the workbench. You will now be able to use SSL when importing profiling data from TMTP.
If you try to disconnect from the network, or switch IP addresses, or switch between wireless and ethernet connections while doing any kind of profiling, or even between profiling sessions, you will experience undesireable results.
To fix the problem, you must restart the workbench and data collectors.
Some connection information is cached in the workbench for performance reasons. Either avoid switching IP addresses, or shut everything down beforehand and restart when you get the new IP.
If your application server is configured for use with the data collection infrastructure, then only the J2EE Performance Analysis and ARM Performance Analysis types are supported. If the server is not instrumented, all types except J2EE Performance Analysis and ARM Performance Analysis are supported.
You cannot use more than one profiling type at a time.
If you want to use other profiling types, you must unconfigure the server, reconfigure it as required by the base product (Rational Application Developer, Rational Performance Tester, or other, as indicated in that product's installation guide), and then do the profiling. To unconfigure the server, see the online help topic "Removing the virtualizer to support other types of profiling." To use the supported profiling types again, you must configure the server to use the data collection infrastructure, following the instructions in the installation guide.
When profiling a live application, some types of transactions are not followed (profiled). These include:
- If a servlet spawns a thread, and the new thread goes off and executes some subtransactions, then these new subtransactions will not be tracked.
- If a servlet is redirected or forwarded, and this redirect causes a new thread to be spawned (even if the thread is spawned by the servlet container), then any transaction events in the redirected servlet will not be tracked.
There are known intermittent problems with installing the data collection infrastructure on Windows Server 2003 machines using either long paths or paths with spaces. Avoid such directories if possible. This applies not only to the target installation directory, but also to the directory from which you are installing.
If data collection fails on Windows 2003 Server, then try running the Agent Controller component as a console application instead of a Windows service:
- Open the Windows Services panel by selecting Start > Settings > Control Panel > Administrative Tools > Services.
- Select the IBM Rational Agent Controller service and stop it.
- Select Start > Settings > Control Panel > System.
- On the Advanced tab, click Environment Variables.
- Click New (if the RASERVER_HOME variable already exists, click Edit). Enter RASERVER_HOME in the Variable name field and x:\dir\IBM_Agent_Controller in the Variable value field, where x:\dir\ is the installation directory. Click OK.
- Open a command prompt and go to the IBM_Agent_Controller\bin subdirectory of the installation directory.
- Run raserver.exe.
- Restart the data collection infrastructure by selecting Start > Programs > IBM Software Development Platform > IBM Rational Data Collection Infrastructure > Stop monitoring, and then Start monitoring.
The security feature of the data collection infrastructure conflicts with Rational Performance Tester recording, and with data collection's dynamic discovery, and is therefore not supported. As an alternative for security, use the Host List option in the data collection installation, and specify a specific list of hosts that can access the data collection infrastructure on the current machine.
In some cases, the data returned from the data collection infrastructure may be missing return messages, and you only receive calls. That is, the UML2SD Class Interactions diagram shows only solid arrows (calls), but no dotted arrows (returns).
To work around this problem, ensure that the clock on the remote machine is set to the same or later time than the workbench machine. You do not have to change the timezone settings. For example, if the remote machine local time is 7:30 and the workbench machine is 8:31 (and the times are correct for the time zones they are in, one hour apart), simply adjust the time on the remote machine to 7:32, or set the workbench machine time to 8:29.
If you cannot possibly change the machine times, send the profiling data to a file specified on the Destination page in the Launch Configuration dialog, and then import that file. For distributed profiling where there are multiple agents, each agent must be attached to beforehand and have the profiling file option set. Each agent should profile to a different file.
The Tivoli Monitoring for Transaction Performance Management Server is set by default to roll up data only once every hour. This means that the data from your test is created, but not collected.
If you do not want to wait until that hourly roll-up happens, do the following:Now, data will be rolled up to the Management Server every five minutes, so data from the instrumented test will be available for import into the toolkit a maximum of five minutes after you run the test.
Open the following file in the TMTP installation directory: config\autorollup.properties
Ensure the tms.autorollup.enable setting is true.
Set the tms.autorollup.period setting to 5, meaning five minutes, which is the minimum allowed value. Values less than 5 will be treated as five minutes.
For each policy you want this autorollup setting to apply to, add the following line:
tms.autorollup.policyN=policy_name
Where N is an integer, starting at 1 (1, 2, 3, etc.) and policy_name is the name of the policy. The resulting autorollup.properties file will look like this:
tms.autorollup.enable=true
tms.autorollup.period=5
tms.autorollup.policy1=myPolicy
tms.autorollup.policy2=yourPolicy
tms.autorollup.policy3=anotherPolicy
Stop and restart the TMTP Management Server.
Note: This rollup setting is applied to instance data. Aggregate data is inaccurate until the hour has passed.
When importing performance data from ITCAM for WebSphere (previously WSAM), there are two authentication layers involved. The first one is WebSphere authentication, which will reject and invalid user/password on the system and cause the toolkit to display an authentication dialog. The other is ITCAM for WebSphere authentication, which will simply return no data available to import if authentication fails.
The only case where WebSphere authentication will pass and ITCAM for WebSphere authentication will fail is when the user enters a valid username on the underlying operating system (e.g. root), but that user is not registered in ITCAM for WebSphere. In this case, users should be aware that the server will not raise an error when authentication fails, but they will instead see no traps available from which to import.
The statistical view, by default, tries to plot one point at each tick in the statistical graph. If there is no point for a given tick, it assumes the point was zero. If the points are too sparse, this results in a line to zero every nth point. This is an artifact created by the graph, and does not reflect what is actually happening on the system. To avoid this artifact, set the behavior to "draw nothing" or "draw previous value" in the "More..." dialog to set advanced options. This will instead draw gaps or straight continous lines where there were no points to plot.
When importing data from an IBM Tivoli Composite Application Manager for WebSphere trap, ensure that the clocks of the management server and the workbench are in sync. In the Tivoli Performance Data import wizard, the option to import the last n units of time uses the current time on the local machine, but queries for traps which have activity in that time period on the management server clock. So if the management server clock is ahead by 10 minutes, you will have to either wait 10 minutes before the import wizard will find this transaction available on the server, or query 10 minutes into the future.
When viewing resource monitoring statistical data in the "Statistical View", if you have the "Link with Viewer" toggle option enabled in the "Profiling Monitor" view, and select a different item, the view will reset itself and automatically turn on the follow-mode toggle option, where the graph follows the current time. To work around the problem, either try viewing the data on a common node (e.g. the monitor) where all the data from the agents will be displayed in the same graph, or simply turn off the follow-mode option by clicking on the ">" button to the right of the horizontal rulers.
When importing response time breakdown data from IBM Tivoli Monitoring for Transaction Performance, IBM Tivoli Composite Application Manager for WebSphere, or IBM Tivoli Composite Application Manager for Response Time Tracking, it is possible to select multiple transactions that originated on multiple hosts, and import them all at once. There is a known defect that causes the data to be stored in a single agent while showing two agents, rather than distributing the appropriate data to each agent. The workaround is to import for each host separately (run through the import wizard once for each host, each time selecting only one host).
Note: This does not affect importing distributed transactions, only importing multiple transactions that originated on separate hosts.
When importing from IBM Tivoli Composite Application Manager for WebSphere, the username/password has to be the username/password used for logging into the IBM Tivoli Composite Application Manager for WebSphere Management Server, not the username/password for WebSphere itself. If you use WebSphere username/password, the import will fail without reporting that failed authentication was the reason. If the username/password does not match WebSphere itself or IBM Tivoli Composite Application Manager for WebSphere, the correct authentication failure message is shown.
When the data collection infrastructure (DCI) starts, it must look up the IP address of the local computer. The DCI uses a call to InetAddress.getLocalHost() to perform this lookup. This call does not always return the correct IP address. An incorrect IP address will prevent the dynamic discovery feature from working correctly. The incorrect IP address can be returned in different situations:
- On Linux, the call sometimes returns 127.0.0.1. This is a known defect in the JVM: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4665037.
- On computers with multiple network adapters installed where each adapter connects to a different network. For example, one network adapter might be connected to a publicly accessible network, while another adapter might be connected to a private network.
- On computers with incorrect entries in the HOSTS files.
If this problem occurs, a critical error will be written to the RPA_MA.log file in the <DCI_INSTALL>/rpa_prod/rpa_comp/logs directory. (The log file is specified by the -Djava.util.logging.FileHandler.pattern=<filename> JVM argument.)
To work around this problem, specify your computer's IP address manually. Add a line to the <DCI_INSTALL>/rpa_prod/rpa_comp/rpa.properties file:
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=<IP address>
For example, if your computer's IP address is 9.67.50.44, you would add the line
IP_ADDRESS=-Dcom.ibm.rpa.runtime.ip=9.67.50.44
Restart the DCI after making the change to rpa.properties.
The performance and problem analysis tools use the Test and Performance Tools Platform (TPTP). Release notes and other documentation for TPTP can be found at http://www.eclipse.org/tptp/home/documents/index.html.
If you are monitoring WebSphere Application Server using IBM Tivoli Monitoring, you must apply the appropriate fix listed at http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=1219396&uid=swg21219396&loc=en_US&cs=utf-8&lang=en to the WebSphere Application Server. These fixes must be applied to the server to resolve issues related to the Daylight Savings Time change.
If you run a schedule from the command line with response time breakdown collection enabled, no response time breakdown data will be collected. To collect response time breakdown data from a schedule, run the schedule from the workbench graphical interface.
When importing response time breakdown data from a Tivoli Monitoring server, you may see one of the following error messages:
IWAY0084E A communication timeout occurred.
IWAY0106E An I/O error occured while importing Tivoli performance data.
In addition, the import wizard pages may appear blank. The WebSphere Application Server logs on the computer where Tivoli Monitoring is located may show an OutOfMemoryError. This problem can occur if you are attempting to import a large amount of data. To work around the problem, narrow the time range for which you are attempting to import data.
If you apply a filter to the response time breakdown table for a particular page element, that filter will be set on all response time breakdown tables you open afterwards. This filter persists for all other page elements in all other tests and schedules. Because this filter persists for all response time breakdown tables, this can make it appear that a subset of the expected data was collected. If the filter does not apply to subsequent transactions then the table may appear blank, giving the impression that no data was collected. The workaround is to remove any filters for a particular page element before opening the response time breakdown results for another page element.
The Application Server Instrumenter modifies the start and stop scripts on BEA WebLogic servers while the server is running. Immediately after instrumenting or uninstrumenting, errors can occur when you stop the server. These can be error messages displayed on the BEA WebLogic console, or unexpected behavior where the server restarts before shutting down completely. These errors occur because the active server process was started with the original start script, but is stopping with the modified stop script.
To work around this problem, make sure the BEA WebLogic server stops completely and restarts using the modified start script. You might need to stop the BEA WebLogic server twice.