kellypuffs 06000168YK Visits (2460)
Pleased to announce the publication of a new IBM Redbook: Rational Application Developer V7.5 Programming Guide.
This book is a collaboration of several Rational Application Developer subject matter experts, including Rational Client Support's own Lara Ziosi and Henry Cui.
This IBM Redbooks™ publication is a programming guide that highlights the features and tooling included with Rational Application Developer v7.5. Many of the chapters provide working examples that demonstrate how to use the tooling to develop applications, as well as achieve the benefits of visual and rapid application development
Table of Contents:
Part 1. Introduction to Rational Application Developer
kellypuffs 06000168YK Visits (1658)
The good folks at ibm.com have just released a new feature which displays the results of our Rate This Page surveys at the top of each document page, like so:
Now, you too can see what feedback has been received on our documentation. As Rate This Page surveys are received, the results are processed, and will be displayed for those technotes.
So this is a good time for me to repeat my call for feedback on the content you find and use on Rational's support pages on ibm.com. Your feedback helps us determine what content is useful and relevant, and what content is not ... so we can fix it! :-)
We're off to see the wizard!
Finally! The 2009 Rational Software Conference is almost here!
We've been primping and preening and prepping and polishing, and this weekend, Rational Support will join thousands of Rational Software fans in travelling to Orlando for what is SURE to be a fun and informative week.
Some stuff I'm looking forward to...
and MOST of all,
If you can't make the conference, hopefully you can follow along at home via the RSC@Home Keynote replays, a Remote RSC event near you, or just follow along HERE, where I'll be live-blogging the event.
AND, we have aflickr pool created. Please join and add your conference photos!
Looking forward to meeting you at the conference!
Jazz.net is live with a completely reworked and improved website
The new Jazz.net site includes the addition of Rational Requirements Composer, Quality Manager, and Focal Point for Project Management. We have done what you asked for and made much more of our Jazz Development open and transparent. Now clients and community members will be able to enjoy the benefits of transparent development but no longer just for Rational Team Concert. Now you can participate with us in shaping plans, prioritizing fixes, and interacting directly with our expanding Jazz Development Team for three new Jazz Products. See http://jazz.net/ for the complete details
eGuide now on Jazz.net
IBM Rational support has taken all the best links from our RSDC eGuide mini-CD and posted them online at http
Check it out!
Rajeshavanthi 2700022MCX Visits (117)
You could see the 'Additional delay' under Client processing delay section for each request, under Advanced tab.
What happens if you make this delay to zero??
Does the play back show much difference in overall response time?
Generally, the time taken to load the entire page outside IBM Rational Performance Tester (RPT) cannot be mapped to the time taken to load the same page when invoked via RPT recorder. There are lot of parameters that RPT, as a load performance testing tool, accounts for (such as the traffic and connection information).
Also, RPT processes these Client side delays in parallel or sequentially depending on how the application server returns them. Sometimes if you try modifying/disabling the client processing delay value, it may also disable the immediate transaction under Rational Performance Tester. Because, practically speaking, when you disable a request, you potentially invalidate some delays because in theory the disabled request could have been the basis for a delay. Therefore, RPT automatically recalculates the delays on the page when you disable a request. That is, if a later request used the disabled one as a base, the later delay request should be adjusted.
Now, let's come to your question about why such discrepancy between the response in the browser and RPT...
Often times when you see response times that are inaccurate it is because of recording your actions too fast and so you end up with more than one page being combined together. When recording, you need to be mindful and make sure to pause between mouse clicks. Do an action and wait 5 seconds before continuing on to the next action. You also need to pay attention to where your mouse is and make sure you have no "hover gifs" that you accidentally cause to be sent to the server while recording.
To see if you have these problems you have two things you can look at.
1. Open the test and click on the name of the test under test Contents in the tree. Click Select->Request. On the right hand side you will see a table of all requests in your test. Look at the delay column and look for really large delay values. If you have these, they are usually caused by recording too quickly, and act as an "embedded" think on the page. The Client Delay is supposed to simulate how long your client took to process the data from the server before sending the next piece of data. When you record too quickly, these values can be skewed. You can also go to a specific page that is taking too long and look at those specific requests. You can use the same Select button, or you can go to the Advanced tab of each request and look at its delay.
2. If you find the delays are your problem, then you can split the page where the delays are long since this was probably supposed to be two pages. This will move that delay to be the think time of the page which would be more accurate. You can also go to Wind
Also remember that when doing recording, we will capture each connection that was used and will send out the requests on the same connection that they were sent on originally. If you had two connections sending requests at record time, we will send requests on two connections at execution time. If you see a really long client delay, then look at that request in detail to determine if it was something that was sent by a user gesture or as a result of the primary request.