Tags

Recent tweets

There are many instances where you get reports indicating higher page response times in the IBM Rational Performance Tester (RPT) generated reports. You tend to correlate these metrics against the usual time behavior noticed when accessing the application under test outside RPT. It could be a case as well where even if you add all the page elements listed in report, the response time is much less compared to overall response time for the transaction.

So let's see how RPT as a load generation tool computes response time metrics.

Generally, the response time is measured from the time the first byte leaves the client machine and until the time that the last byte is returned.

The page is considered to begin when the first action (typically a request) associated with the page starts execution. If this request needs to make a connection, the page response time will include the connection time. The page ends when the last action (usually a response) of the page completes. RPT would adjust the page response time to remove the time spent in client delays. In RPT 8.2 this changed after determining it was more representative of the real-world response time to leave the client delays in the page response time. Thus, in RPT 8.2 and later, the page response time does include client delays.

However the Think Time value set in the schedule is not included in the page response times displayed in the Performance report. It should be noted that there are potential "delays" in the script that could increase page response times. Think times are associated with pages and are intended to represent human pauses during recording - these don't impact page response times. For individual page elements (requests), there may also be delays which are intended to represent client (browser) delays (processing time for example). These will be reflected in page response times

Questions could arise such as: How does RPT calculate the Page level response time as compared to Request level response time for a given page?

In case the first request used a new TCP connection, it calculates the difference between the timestamp when the connection for the first request in the page was made and the timestamp of when the last byte was received for the last request in the page. In case an existing connection was reused, the timestamp of when the first request was sent is used. All these timestamps are available in the test log if full logging is on. If a existing TCP connection is re-used, the value "Time to Connect" in the test log will be 0 .

Rational Team Concert server is expected to have a common user base management. In order to correctly perform process enforcement for Git operations by Rational Team Concert it is imperative that the identity of the Git user be known to Rational Team Concert. Therefore, the need to have a common user base across Rational Team Concert and Git server (Apache HTTP server) via a different LDAP arrangement.

We can still get the integration done using a common user name with different user base across Rational Team Concert and Git server via an different LDAP arrangement.

Example: Git is configured with Apache DS LDAP and RTC configured with different LDAP registry.

Note: Common user id used for both GIT and RTC using different registry (with different password) and provide all necessary permissions.

Below are checkpoints for verifying the integrations:

1) Verify the GIT login, just to ensure GIT login is fine

$ git remote show origin

2) Verify the GIT GIt repo configuration

c:\Apache24\gitrepo\jke.git\config

Update respective "repokey" and "repourl" information

3) Verify the GIT GIt repo configuration

c:\Apache24\gitrepo\jke.git\hooks

Update respective "pre-receive" and "post-receive" hooks information

Note: The above configuration will give a clear understanding about RTC-GIT integrations and using a common user name with different user base across Rational Team Concert and Git server via different LDAP arrangements.

Post upgrade of your CLM application you may come across the below error while trying to access any Project Areas in Rational Quality Manager.

The error occurs when QM is not deployed correctly which could be the result of an incomplete / improper upgrade process and when WebSphere cache was not cleaned prior to deploying 5.0.2 war file.

Checking the logs reveals the below error:

2015-07-14 11:16:53,549 [ WebContainer : 2] WARN ComponentVersionMismatch - CRJAZ1041I The component is installed in the database but is not present in the server: com.ibm.rqm.reporting
2015-07-14 11:16:55,077 [ WebContainer : 2] ERROR ompatibility.internal.JtsConfigurationStateService - CRJAZ2679E The JTS version could not be determined because the JTS rootservices document at "https://<FQDN>/jts/rootservices" could not be fetched or does not have an about services URI.

You may follow the below steps to redeploy QM:

1. Undeploy QM.war

2. Clean the WebSphere Cache by following these steps:

a) Stop the WebSphere service
b) Delete the files from the below locations:

a) Go to Applications > Application Types > WebSphere enterprise applications.
b) Click the jts_war application, and open it for editing.
c) In the Detail properties section, click Security role to user/group mapping.
d) Select a specific repository group, such as JazzAdmins or JazzUsers, and click Map groups. These repository groups are associated with every Jazz implementation and must be mapped to a particular group that contains the authorized users. If you are using LDAP, these groups must be set up on the LDAP server prior to completing this mapping. If you are mapping these repository groups to individual users, select the repository group and click Map Users.

e) Enter a search string to return your group names from the LDAP server. Click Search to run the query.
f) From the list of available groups that is returned, select the particular group and move it to the Selected column.
g) Click OK to map the LDAP groups to the Jazz repository groups.
h) Map the appropriate LDAP group for all Jazz repository groups:

In IBM Rational Reporting for Development Intelligence (RRDI) or Insight, custom enumeration attributes and values are not stored in the same tables and need other joined queries to access the values in your report.