RPT Schedule execution on local machine results in error: com/ibm/lang/management/OperatingSystemMXBean
Rajeshavanthi 2700022MCX Visits (467)
IBM Rational Performance Tester (RPT) supports schedule execution to be carried out on a separate controller machine (Agent machine), which in fact is a recommended way of script execution. It also supports, to an extent, executing the minimal amount of user load execution locally on the workbench machine (not recommended for production level testing).
When executing a schedule under RPT
The following attempts were made to debug this further:
dmmckinn 1200006SCS Visits (557)
We'll be back tomorrow with more great content focused on helping you get the most out of IBM Rational Support and your IBM Rational products!
As we begin to wind down from our summer season activities and our children return to school, it is time to celebrate this American federal holiday. This is a day where we recognize the contributions of the American worker. It is a day where we take some time off to relax and enjoy the company of our family and friends while sharing our favorite backyard barbecue.
While we are off for the day we want to share with you a list of videos that have been posted on this blog. Enjoy this CLM video collection.
GlennSkinner 110000DAAT Visits (526)
Everyone has them, you know, those ages old ClearQuest records with a never ending string of history records. Records so long that you go for coffee while the record is loading. We all know them far to well. They are the bane of ClearQuest admins world wide. Well not any more. Beginning with the release of feature level 9, now we have choices.
We now can:
* Turn off history all together.
* We can turn it off for some actions and not others
* We can defer loading the history until we need it.
All of these new features opens a whole new world of management options. My favorite is simply defer loading the history. If we are making an update to a record, most of the time we don't need to see the history, so why wait for it to load. With this feature there will be a load history button on the history tab. if you need to see the history, simply click on the button. Any modification to the record, or refresh will cause the history to be discarded from memory and you will again be presented with the button.
Simple clean and neat.
For more information on these new features see the following links:
GlennSkinner 110000DAAT Visits (590)
You just upgraded WAS 8.5.x to the latest fixpack and after restarting the services, ClearQuest can no longer be accessed through port 80. You discover that you can reach it on port 12080. On closer examination, you realize the plugin-cfg.xml that is referenced by the httpd.conf file has been overwritten. How do you fix it? If you follow these simple steps below, you should be back to normal before you know it.
It turns out the httpd.conf file is not pointing to the plugin-cfg.xml being used by WAS. The file specified in httpd.conf has incorrect server paths. Propagation will fix this mismatch.
To fix this:
1) login to the WAS admin console http
2) On the left of the console expand Server -> Server Type -> Web Server
3) When the propagation is finished, Click on "<yo
4) navigate down the page and click on "Copy to web server key store directory"
Should you still have issues after performing the above, check the plugin log file for any errors.
Rajeshavanthi 2700022MCX Visits (727)
There are various performance testing tools in market and it's advisable for a tester to do a sort of comparison in-terms of the product functionality.
Under Load Runner you could see following options made available
So there could be questions as to whether RPT provides similar functionality or how would the virtual user execution gets handled in RPT.
What happens if you specify 100 virtual users in the RPT schedule. Say, you have 10 user groups each one has an unique script with it. So10 users per user group, totally 100.
RPT does not require a thread per test not it does require a thread per virtual user. When an individual action is being executed one thread is used.
One example of an action is an HTTP request. One thread is required to open a connection, if necessary, and write the request. Reading the response from the server is non-blocking. When data is available one thread is required to read the data and perform any processing required. Another example of an action is Custom Code. During the execution of the Custom Code exec() method one thread is required.
In general, For the HTTP protocol the RPT engine will create a thread as needed up to a maximum of 500 threads. The need to execute an action (eg request send or response) and unavailability of a free thread is what controls creation of additional threads.
Unless there is some specific problem it is highly recommended to let RPT control the creation and deletion of threads.
So, if you are looking it specifically from RPT perspective, then the agent starts execution with 10 worker threads
However if you are interested to control the threads, then the following system properties can influence thread control. These apply to the execution engine (ie location or agent) so a general property for the location must be created to set these system properties. For each location you must create a property called RPT_VMARGS and set it accordingly.
The default values are
-DrptThreadCount=10 (Initial number of worker threads)