LR CI Variables

Setting LoadRunner CI variables directly in Jenkins

One side issue with running CI from Jenkins is with controlling the test runs and making them more configurable. I don’t want to have hundreds of different LoadRunner scenarios for every automated test I need to run. Rather, I want a small set of scenarios per project, with allowance for changing environments, runtimes and base urls from within the Jenkins build screens. Possibly with scope to change call ratios and TPS rates as well.

For the moment, due to commercial considerations, this page will just outline my approach to this problem. Possibly at a later date I can upload some working scripts.

A simple example
I want to run a CI test on one of my projects with two different setups, in fact pointing to two different environments: ‘perf’ and ‘stage’. I already have Jenkins jobs for bringing up the perf environment and tearing it down after a successful test. Now I want to configure my LoadRunner test (Jenkins build) to point to that env. BUT I don’t want to have to go into all my scripts, change the parameters from within dialog boxes, recompile etc. This needs to be quick and easy.

Solution
In fact I’ve got a bit of overkill in my solution but you can pick the best format for your needs.

Quite a few of my current projects use VTS for storing runtime data, so I thought I’d use this for setting variables. But then you need to specify which VTS server to use - and since I have multiple projects running in parallel, I need to be able to specify different setting per test run at the same time and thus do sometimes need to change the VTS server for any particular test run.

But this means I need to be able to change (at least) the VTS server variable, without using VTS!

So I have:

Method 1:

  1. Have a bash script run in Jenkins and add variables to a file in the script
  2. Have a function in the init section of the script to read in these variables and set them as parameters
  3. Add a transaction to the test run just to report what settings we are using

The bash script (which runs on the Jenkins slave controller) does this:

    cd /cygdrive/z/loadrunner/scripts/myproject/script1
    #if you want to remove current variables set in this script uncomment the following line:
    sed -i '/lr_variable/d' ./globals.h
    echo "//lr_variable environment=perf" >> globals.h

    cd /cygdrive/z/loadrunner/scripts/myproject/script2
    #if you want to remove current variables set in this script uncomment the following line:
    sed -i '/lr_variable/d' ./globals.h
    echo "//lr_variable environment=perf" >> globals.h

The init section of the script then reads these variables in from global.h (a standard file in every script):

    get_globals_file_lr_variables()
    {
       if ((file_stream = fopen("globals.h", "r")) != NULL )
       {
           while(fgets(line, 1024, file_stream) != NULL)
           {
               equals = (char*)strchr(line,'=');
               if(strstr(line,"//lr_variable") == line && equals)
               {
                   do some string manipulation and pull out the variable name and value
                   lr_save_string(value,name);
                  
                  

Step 3, which I have set up myself in method 2 below, would then be to use lr_set_transaction to set a ‘value=name’ transaction so this can immediately be seen on the load test front end.

Method 2:

With this method (which I tend to use in practice, I use all the above code to set the VTS server ip address and then I set my other variables in VTS itself and read them out with another function.

This method works better for me as I rarely have to change the VTS server for any particular project and then I can quickly and easily change environment variable in one place and each script picks it up. I guess this is not really needed since you could just set those variables in bash....

Anyway, I’ll leave it to the reader to decide.

So, when using Method 2, my vuser_init() section looks like:

    vuser_init()
    {
       int rc;
     
       lr_save_string(VtsServer,"VtsServer");//set default hardcoded value first
      
       get_globals_file_lr_variables();
      
       //see if vtserver is set
       if(strlen(lr_eval_string("{VtsServer}")) > 0)
       strcpy(VtsServer,lr_eval_string("{VtsServer}"));
      
       rc = lrvtc_connect(VtsServer,VTnPort,VTOPT_KEEP_ALIVE);
       lr_log_message("Connect result rc=%d\n", rc);
       if(rc != 0)
       lr_exit(LR_EXIT_VUSER, LR_FAIL); //we need VTS for this project in general, not just for global      settings
      
       get_global_VTS_lr_variables();

       log_local_ip();
     
       srand( time(NULL) );

       make_note = 0;

       web_set_sockets_option("SSL_VERSION","TLS");

       lr_load_dll("pcre3.dll");
       iteration = 0;

       return 0;
    }

The log_local_ip() function launches a command line on the injector and set’s a transaction with the local ip address. This is just a quick and easy way to see in the summary report how many injectors we are using.

srand() should only be called once per user, so do that here. I use make_note to put another transaction in the summary, just once per user, just to confirm exactly where we are pointing - so this uses whatever environment variable is ultimately set to make a note in the summary report.

All this transaction logging is really aimed at CI in Jenkins so you can quickly see what settings were used. But it is is usefully generally as well, especially when you are running tests across different environments, typical in agile setups.

Typical output in the summary report:

image00117

New requirement - Just in: Adjusting scenario SLAs from within Jenkins

Another issue that has come up is adjusting the SLA values in a scenario without having to load up in LoadRunner, go through all the dialog boxes, click click click, save the scenario, get it on to all our controllers etc.

Instead, we just want to change the values directly from Jenkins so we can fine tune the builds to allow for SLA adjustments over time to stop unnecessary build failures.

Solution

If you look through a .lrs scenario file you can see how it all fits together. So we use a simple bash script to set SLA values before running the scenario through Jenkins. These can then easily be adjusted as time requires. So in the first shell script of the build, we run this script:

(as always with these bash scripts, do watch out for windows style newlines, you want linux ‘\n’ only endings.)

echo adjust scenario 95th percentile SLAs
cd /cygdrive/c/loadrunner/scenarios/all4
pwd
lrs_name='all4_run_test.lrs'
echo adjusting ${lrs_name}
part1='<PercentileRule Name="transaction_response_time_percentile_'
part2='"><Percentage>95</Percentage><Value>'
part3='</Value><Measurement>transaction_response_time_percentile</Measurement><SubMeasurement>'
part4='</SubMeasurement></PercentileRule>'

tx_names[0]='atoz'
new_values[0]=0.2

tx_names[1]='brands'
new_values[1]=0.35

tx_names[2]='collections'
new_values[2]=0.35

tx_names[3]='collections_asset'
new_values[3]=0.1

tx_names[4]='on-now-new'
new_values[4]=0.25

tx_names[5]='on-soon-new'
new_values[5]=0.25

tx_names[6]='pictures'
new_values[6]=0.2

tx_names[7]='profiles'
new_values[7]=0.2

i=0
while [ $i -lt ${#tx_names[*]} ]; do
   echo setting ${tx_names[$i]} new value to ${new_values[$i]}
#echo sed -i 's^'"${part1}${tx_names[$i]}${part2}"'[0-9]*.[0-9]*'"${part3}${tx_names[$i]}${part4}"'^'"${part1}${tx_names[$i]}${part2}${new_values[$i]}${part3}${tx_names[$i]}${part4}"'^' ${lrs_name}
sed -i 's^'"${part1}${tx_names[$i]}${part2}"'[0-9]*.[0-9]*'"${part3}${tx_names[$i]}${part4}"'^'"${part1}${tx_names[$i]}${part2}${new_values[$i]}${part3}${tx_names[$i]}${part4}"'^' ${lrs_name}
   i=$(( $i + 1));
done

echo finished adjusting scenario SLAs

 

[Home] [About (CV)] [Contact Us] [JMeter Cloud] [webPageTest] [_64 images] [asset moniitor] [Linux Monitor] [Splunk ETL] [Splunk API] [AWS bash] [LR Rules OK] [LR Slave] [LR CI Graphs] [LoadRunner CI] [LR CI Variables] [LR Bamboo] [LR Methods] [LR CI BASH] [Bash methods] [Jenkins V2] [Streaming vid] [How fast] [Finding Issues] [Reporting] [Hand over] [VB Scripts] [JMeter tips] [JMeter RAW] [Dynatrace] [Documents] [FAQ] [Legal]

In the Cartesian Elements Ltd group of companies