Posts Tagged LoadRunner
Creating Oracle 12 Scripts on LoadRunner
Posted by Martin in Performance on August 31st, 2009
After receiving several questions about the new Oracle 11 protocol on LoadRunner and the version 12 of the E-Business suite, I thought it would interesting to give a few tips about these technologies too.
Oracle Web Applications 11i is the new protocol used by the newer LoadRunner versions to script the E-Business suite. The advantage of it is that you can use a single protocol to script the application instead of using the multi-protocol approach. This can be useful if your license is limited or you don’t want to spend more money on protocols that you don’t have. Another advantage is that this protocol can be used to script the newer version of the E-Business suite, 12.
Tip 1: Correlating the Login
After recording your basic script, the first thing you will have to correlate on the Login is the ICX ticket.
In order to do do this, you will have to add this command right before clicking on the functionality link:
web_reg_save_param("ICX",
"LB=var xgv15 \= \"",
"RB=\"\n",
"Search=Body",
LAST);
Eg.: If you accessing the “Submit Processes and Reports” functionality for example, you will have to add this code right before the “web_text_link(“Submit Processes and Reports”…” line.
This parameter will be used later on the “nca_connect_server” and “frmservlet” requests. On both requests, look for the “icx_ticket=” part of the URL and replace the code to your parameter ({ICX})
You will also need to correlate another session parameter that sometimes is not correlated automatically and sometimes is wrongly correlated when you’re recording the script.
Look for the “web_url(“frmservlet”…” line mentioned above and add the following block BEFORE it:
web_reg_save_param("Jsession",
"LB=/forms/lservlet;jsessionid\=",
"RB=",
"Search=Noresource",
LAST);
This will create the “Jsession” parameter that will be used on another call before the “nca_connect_server” call.
Look for a line that starts with “web_url(“lservlet;jsessionid=” and replace on the URL parameter the large string that comes after “/lservlet;jsessionid=” with your parameter. Remember, do not replace the large session string on the title (first parameter), but on the URL parameter. Eg.:
web_url("lservlet;jsessionid=5ce9bad22e40aa7f7f9c4cff2549fc09a968476354cb39d14a0bd8636339170b.e38NaN0ObNiKai0LbNiSchaRaNaMe0",
"URL=http://<you_application_server>/forms/lservlet;jsessionid={Jsession}?ifcmd=getinfo&ifhost=XXX&ifip=10.10.10.10",
To summarize things you will have to do 5 things.
- Capture the ICX paramter
- Replace the ICX parameter on the frmservlet call
- Replace the ICX parameter on the nca_connect_server request
- Capture the Jsession paramter
- Replace the Jsession parameter on the lservlet;jsessionid= call
This should also work if you’re scripting against an Oracle 11 application with the new LoadRunner protocol.
And remember, this has worked for me, but may not work for you depending on how your application was deployed and configured.
Tip 2: Recording Sessions with HTTPS (SSL)
Your application may be configured to use SSL (HTTPS connections). If this is your case, you probably won’t be able to record your scripts directly since LoadRunner is not able to identify which server you’re connecting to.
To solve this issue you will have to manually add your application server address and port before recording.
Click on the “Options” button on the lower left corner of the recording window (before you start recording).
Select “Network > Port Mapping” on the left side pane and click on the “New Entry” button. This screen should be presented:
Target Server and Port are respectively your application server address and port. Service you can leave as “Auto Detect”. Record Type you can leave as “Proxy”. Set Connection type to “Auto”.
This will enable the SSL Versions and SSL Cyphers fields. With this fields you will have to check with your application administrator or spend some time “guessing” the correct configuration.
Click on Update and start recording the script. If everything was set correctly, LoadRunner should be recording your actions inside the application as usual.
Recording Citrix scripts on LoadRunner
Posted by Martin in Performance on August 7th, 2009
A few weeks ago I’ve came to find an interesting article about the Citrix protocol on LoadRunner, with a few best practices that may make your life easier if you really have to record Citrix scripts on LR.
Since I got a lot of replies on my previous Citrix post (How to evaluate the response time of a Citrix application), I though that it would be a great addition to share this article with you.
Performance Testing Citrix Applications With LoadRunner [UPDATED LINK]
I’ve been also working with another tool to test Citrix application. It is developed by Citrix itself and it’s called EdgeSight for Load Testing. So far it seems to work very well and it’s easier to record the scripts in it (synchronization commands are added automatically). If you have the time and money to test this tool I would say that it’s worth a shot.
If you’re facing the same issues as me, let me know of your thoughts!
How to script Oracle 11i Apps on LoadRunner
Posted by Martin in Performance on August 5th, 2009
A lot of people came to me on the last few weeks asking about Oracle Apps scripts. As I’ve been noticing during the last year, Oracle Apps (Financial) is dominating the ERP business and growing in a gigantic rate.
As I like to say, “Oracle is the new thing today”. Everybody is changing to Oracle, developing new solutions on their platform and I don’t have to say that also, creating new challenges for Performance Testing. For our luck, my opinion so far is that Oracle Apps do very well regarding performance if well designed and configured.
Obviously I’m not here to talk about Oracle Apps itself, with their search queries and concurrent requests. I’m here to give a few tips based on the things I learned while testing Oracle Apps.
Before I start, I just want to point that this is only one example of how things worked for me. If you’ve been on Performance Testing for a while, you should know that there are several ways of doing the same thing. Most examples were tested using LR 9.5 and Oracle 11i. I know that most tips can also be applied to LR 8.1, 9.1 and also Oracle 10.
Tip 1: How to correlate the Login?
Login is usually the tricky part of the Oracle Apps. The way I usually do is to use a multiple protocol script, HTTP and Oracle NCA. I know that the newer versions of LR have a specific protocol for Oracle Apps, but this has worked pretty well for me.
To make things easier, let’s record the steps from the web interface first. Don’t forget to add some comments, Each click on the web interface generates several requests and sometimes the same happens inside the application too.
All very simple so far. If you done the right things so far, LR should be capturing all events, both on the web interface and the Oracle interface. Once you’ve finished and LR generated the basic script, the tricky correlations come in.
On most cases, you will be using more than one application note. This means load balancing. In order to do this, the web front-end will send you a node name, port and domain.
To capture this information, use the following lines on the first request made when selected a form. Right before the “RF.jsp” call.
web_reg_save_param("serv_name", "LB=var xsname = \"", "RB=\"", LAST);
web_reg_save_param("port_num", "LB=var xsport = \"", "RB=\"", LAST);
web_reg_save_param("domain_name", "LB=var xdname = \"", "RB=\"", LAST);
This will capture the required information for the load balancing. Now let’s concatenate this and create a connection string. Add this right after the “RF.jsp” call.
lr_save_string(lr_eval_string("{serv_name}{domain_name}"), "serv_name");
Now that we have the connection string, we need to capture some variables needed for the connection, like the form to be launched, some profile information, etc.
Right after the command above, add the following lines:
web_reg_save_param("nca_connect_1", "LB=<PARAM name=serverArgs value=\"", "RB= config='", LAST);
web_reg_save_param("nca_connect_2", "LB=var xform_params = \"", "RB=\"\n", LAST);
web_reg_save_param("nca_connect_3", "LB=var xenv = \"", "RB=\"\n", LAST);
Now that we have captured all information we need to connect, let’s change the connection line. Replace the “nca_connect_server” line to:
nca_connect_server("{serv_name}", "{port_num}", "{nca_connect_1} record=names {nca_connect_2}::{nca_connect_3}");
All done! Now you should be able to execute the Login correctly.
Tip 2: How to record the correct field names?
If you recorded a few scripts and you’re having problems with missing fields on second and subsequent interactions of your script, that’s probably because LR is not recording the filed names correctly. Oracle, depending on how it was configured, selects random field names depending on the interaction, usually plain numbers.
In order to solve that, you will have to change some configurations on your profile or default profile on Oracle. Obviously, you will need rights to change this information and usually to change the default profile, you will need the SYSADMIN user.
OK, all rights granted. Follow these steps:
- Open the Web Interface;
- Login with your user (or SYSADMIN);
- Select the role “System Administrator”. If you don’t have this role, you don’t have the rights to do this;
- Select the option “Profile: System”;
- Search for the following profile option: “ICX: Forms Launcher” (Search for a specific user to change only the settings for one user);
- Append this string to the end URL: “?play=&record=names”;
- Save and close everything;
- Try recording the script again.
ps.: Sorry if you already recorded all your scripts, you’ll have to do it again to get the field names right.
Tip 3: Other profile settings
These settings are not required, but are best practices gained though time. Change the following profile options the same way you changed the “ICX: Forms Launcher” option before:
ICX:Session Timeout: 3000s: Use this profile option to enforce an inactivity time-out. If a user performs no Oracle Applications operation for a time period longer than the time-out value (specified in minutes), the user’s session is disabled. The user is provided an opportunity to re-authenticate and re-enable a timed-out session. If re-authentication is successful, the session is re-enabled and no work is lost. Otherwise, Oracle Applications exits without saving pending work. If this profile option to 0 or NULL, then user sessions will never time out due to inactivity.
ICX: Limit time: 999h: Use this profile option to specify the absolute maximum length of time (in hours) of any user session, active or inactive.
ICX: Limit connect: 2000: Use this profile option to specify the absolute maximum number of connection requests a user can make in a single session.
Hope these tips will help you facing the “Oracle Challenge”!
First result on a Google Search
Posted by Martin in Uncategorized on August 5th, 2009
A colleague called me on the IM yesterday with some great news. He was searching for some information on LoadRunner and came out with the following search query:
load runner response server size
Guess which page came as the first result from Google? This very own blog.
Good thing for me that my blog is being quoted by other blogs and growing in popularity. Good thing also for him that didn’t have to go too far to get his answer.
ps.: Yes, I know that this is not a search query that you will come up with every day!
How to evaluate the response time of a Citrix application
Posted by Martin in Performance on March 24th, 2009
This came to my attention on the last few weeks since several projects came with this request and nobody had done this before.
First of all, I’d like to explain a little bit about how the Citrix protocol works on LoadRunner.
Once LoadRunner establishes a connection with the Citrix server, we have two kinds of transactions, Outbound and Inbound. The first comprehending keystrokes and mouse gestures going from the client to the Citrix server. The second comprehend window commands and screen refreshes going from the Citrix server to the client.
Differently from other protocols, were we send a package (HTTP post, WebService call, etc) and wait for the response to measure the response time, the Citrix protocol does not have this kind synchronization. Basically what happens is, we send a keystroke for example, the server responds with a acknowledgment, and that’s it, there is no way of knowing if the applications has processed the request and presented the results. Basically, there is no synchronization between Inbound and Outbound transactions.
In order to measure the response times for Citrix transactions, we need to find a way to “understand” what is coming from the Citrix server and manually synchronize it. There are two ways of doing that, the first is to monitor for window changes, like a window opening, etc. The second is to monitor a part of the screen for a refresh. The problem with both of them is to predict what is going to change, like the name of window that is going open or which part of the screen will refresh. This makes the scripting part really difficult and time consuming, because we cannot predict exactly what is going to be changed, like for example, we’re monitoring for a screen change, but an error message appears, the script will understand that there was a change on the screen and continue, consequently crashing.
Another point to notice is that Citrix is a proprietary solution, based on a widely know protocol (RDP). RDP’s performance is based solely on the bandwidth capacities and being a proprietary solution, we cannot change the protocol, consequently, we cannot increase the performance of the protocol, we can only work with the bandwidth between the Citrix server and the client. This bandwidth varies too much from time to time (peak hours, etc), so the results will vary a lot depending on the time we run the tests.
Based on this assumption, in order to have reliable results, we need to run several rounds of tests during different times, so we can have an idea about the overall performance.
Assuming these problems, I tried to find different ways of getting the response times from Citrix applications. Based on a few articles on the subject, I found that there are more reliable ways of doing that, other than using LoadRunner scripts to capture response times.
Going back to the requirements, we can separate the measure of “response time” to do certain action into three steps. The first is the time it takes from sending a command from the client to the Citrix server. The second is the time the application takes to process that request. The third is the time it takes for Citrix to send the screen refresh with the results to the client. So:
Send Keystroke + Time to Process + Send Screen Refresh = Overall Response Time to Perform an Action
On most cases it is easy and reliable to measure the “time to process” each action locally, without Citrix, so what we need to measure is the time it takes for sending a keystroke to Citrix and the time it takes for the client to receive the screen refresh. Basically is the delay of sending a keystroke and the delay of receiving the screen.
We know that this delays are affected mainly by three factors, the bandwidth limitations, the latency and the amount of data transferred. The first step is to find out how much data is transferred. We can do that by two ways, one is to use a sniffer on the network to capture exactly how much data is sent and received on each transaction. The second is to estimate this amount based on known factors.
For the outbound transactions, this is quite easy, since mouse gestures and keystrokes usually consume the same bandwidth. For the inbound transactions we know that the RDP protocol uses JPG compression to send the screen refreshes, and it only sends the updates for the parts that were changed. This way we can estimate the amount of data transferred by using a simple formula to calculate the JPG size using the image size, density and color content of the refreshed areas.
Knowing the amount of data to be transferred on inbound and outbound transactions we have two options to know the delay. The first is to measure the Round Trip Time (RTT) from the Citrix to the client and the client to the Citrix server, using the amount of data estimated before. The second is to estimate the RTT with known formulas, that use this three factors to estimate the probable delay on the RTT.
After all this technical explanations, I believe that the best solution is to:
- Measure the time to process each action locally, without Citrix.
- Estimate the average amount of data transferred from the client to the Citrix server, using the standard values for keystrokes and mouse gestures.
- Estimate the average amount of data transferred from the Citrix server to the client on the screen refreshes, using captures JPG images of the updates screens.
- Measure the RTT with the estimated data for the outbound transactions on different times. This can be easily done by a network engineer once we know the amount of data.
- Measure the RTT with the estimated data for the inbound transactions on different times.
- Sum all this measures and define our average response time to execute an action over Citrix.
This way we have more reliable results, already on a fine grain, making it easier to identify problems, since we will know if the response times are high on the processing part or the Citrix part.
Note that we’re not trying to measure the Citrix server performance from a load perspective. There are known metrics for Citrix servers that usually satisfy the sizing requirements.
