Common Issues While Creating Performance Scripts

When you start load testing a web site (especially if this is the first load test in your life) you may see a lot of errors in the report. Possibly you will even have to stop the test before it completes, because at some point in time it becomes clear that something goes wrong. If the problem is not so obvious, it is still recommended to check the report for the errors related to each virtual user profile (i.e. to each different type of virtual users) before looking at any performance data.

Issue 1:  

Most probably the errors appear because you have not parameterized the HTTP requests in your profile. Note that initially all requests are recorded as is. If user use a recorded profile without any modifications. Performance tool will simply repeat all the same requests with the same values of all parameters. However some values should be unique for each session.

You can check the “Logs” folder for errors and find the first request that produced an error. The goal is to find dynamic session-specific values inside that request. You can do this by comparing different sessions. Usually such session-specific values are contained inside the request parameters, but they can also be passed inside the main part of the URL. When you find such value you also need to find a place (the body of one of the previous responses) from which you can extract it. You can use the “Edit | Find and Replace…” feature for that.

Issue 2:  

Let’s imagine that you have done good work on the parameterization and now when you verify your profile, it does not produce any errors, and each new session completes as expected. Now you try to execute a small test with several concurrent users, and you see that it fails for all users except the first one. The problem may be that your web site does not allow several concurrent sessions with the same user credentials. This means that you need to use a different user name and password for each virtual user.

After you make all necessary modifications to the profile you can enable the full logging to check that all user names and passwords are passed correctly. By default logging is enabled only for verification, but if you run test with just few users, you can switch to full logging without any significant performance overhead.

Issue 3:  

Even in case the user credentials are passed correctly, you may still see that almost all sessions complete with errors. This may be because some session-specific values still require parameterization, because they depend on the user account. Basically this is the same problem as the first one. I only wanted to note that you may face it again when you switch from one user to many users test.

For example, it may be that each user of your system has a special ID which is passed in some parameter of each request. If you use a different user name, you also need to change that ID. As usual the right value can be extracted from some response and assigned to a variable.

Issue 4:  

Your web application may require authentication. This is not exactly the same as entering the user name and password in some form on a web page and clicking the “Sign In” button. When you use a browser to access a site requiring authentication, it displays a separate dialog asking for credentials. Since this is done in a secure manner, it is not possible to record the credentials automatically

Issue 5:  

There is one very important rule that you should apply when creating a new virtual user profile: always start recording by entering the landing page URL into the address bar and always delete cookies and browser cache before recording. This is not just a good advice; this is the only correct practice.

If you start recording from the middle of a user session, your load testing tool will not be able to reproduce that session correctly. Even if you click a link on a page already open in your browser instead of manually entering the address, this can produce incorrect recording.

The same will happen if you do not delete cookies. Your web site may behave differently for new users and for returning ones. It may use cookies to restore the previous session. If you record such restored session, you will not be able to emulate a new one.

Finally, if you do not delete browser cache, all requests to cached elements will be skipped on recording. This is the least important problem, because any session-specific requests will be sent in any case, but to create a realistic load you will probably want to load page elements as well.

Important Note:

If you see errors in the report, you should definitely research the problem as described above. However even if you do not see any red lines in the log, this does not mean that everything works correctly. Your web site can produce errors in a “user friendly” manner or just redirect to a different page if it cannot provide valid content for a request containing incorrect parameters. This means that you need to read the actual response to see if it is correct. Again, you can use the “Compare with recorded” function and check all responses step by step.

HOW TO UNINSTALL JENKINS

How to uninstall Jenkins on Mac system

1.    Execute from terminal

          /Library/Application Support/Jenkins/Uninstall.command

2.    Or use Finder to navigate into that folder and double-click on Uninstall.command.

3.    If the uninstallation script cannot be found, use:

      sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist

      sudo rm /Library/LaunchDaemons/org.jenkins-ci.plist

      sudo rm -rf /Applications/Jenkins "/Library/Application Support/Jenkins"     /Library/Documentation/Jenkins

4.    if you want to get rid of all the jobs and builds:

  sudo rm -rf /Users/Shared/Jenkins

5.  to delete the jenkins user and group (if you chose to use them):

       sudo dscl . -delete /Users/jenkins

       sudo dscl . -delete /Groups/jenkins

  Baby Products

Jmeter bean shell script, create file, read jmeter variable value, store script variable value into jmeter variable

Hi All,

Some times in JMeter scripting we need to store the output value in file or wanna show the run time  variable value in console window. OR we need to get the current JMeter script directory path. This can be achieved via scripting in Bean Shell Pre/Post Processor.

Here I am using time and counter function of JMeter to create the file.In bean shell scripting we are reading the JMeter variables value and storing script variable value into JMeter variable or creating Jmeter variable

Here is the  Bean Shell script :

import org.apache.jmeter.services.FileServer;
import org.apache.jmeter.services.FileServer;
import java.util.Date;
import java.text.SimpleDateFormat;

SimpleDateFormat formatter = new SimpleDateFormat( "yyyyMMddHHmmss" );  
String datetime = formatter.format( new java.util.Date() ); 

// Get current running counter value(C refrence name deifned in counter config element)

String counter= vars.get("C");

// Get Jmeter variable value in bean shell script by vars.get method

String timer= vars.get("JmeterTimerVariable");

// here JmeterTimerVariable defined in User Defined variable  config element


//  Display value in Console 

System.out.println("Current counter value = " + counter);

System.out.println("JmeterTimerVariable value = " + timer);


// Store beanshel script variable into Jmeter variable by using vars.put method and we will user this jmetervariable in Wikisearch http request

vars.put("JmeterSearchVariable",datetime+counter);

// get JmeterSearchVariable value in beanshell script

String SearchVariable = vars.get("JmeterSearchVariable");

System.out.println("SearchVariable value = " + SearchVariable);

// Here we can get the directory path of Jmeter script file

String DirPath = FileServer.getFileServer().getBaseDir();

// write into jmeter.log file under Jmeter/bin directory

log.info(DirPath);

System.out.println("Directory path of Jmeter script file = " + FileServer.getFileServer().getBaseDir());

// we will create a file under directory of jmeter script file with name JmeterReords using File system True file will be created if not and data will //append into the file False will create a new file with fresh data

f = new FileOutputStream(FileServer.getFileServer().getBaseDir()+"\\JmeterReords.txt", true); 
p = new PrintStream(f); 
// write data into file 
p.println("Current counter value = " + counter);
p.println("JmeterTimerVariable value = " + timer);
p.println("Directory path of Jmeter script file = " +DirPath);
p.close();
f.close();

// if you want to create unique file for each loop counter refer below script

String uniquefilename = timer+counter;
f = new FileOutputStream(FileServer.getFileServer().getBaseDir()+"\\"+uniquefilename+".log", true); 
p = new PrintStream(f); 
// write data into file 
p.println("Current counter value = " + counter);
p.println("JmeterTimerVariable value = " + timer);
p.println("Directory path of Jmeter script file = " +DirPath);
p.close();
f.close();

Here is the structure of JMeter script

Jmeter bean Shell script

Jmeter: pass a value between threads

Synopsis: 

Find out ways to pass a value between threads (i.e. capturing a value in one of the thread and passing it to the other thread in the same test plan).

Tool Used:     JMeter: Performance testing tool.

Solution:       Sharing Variables

1)      Used Sampler : BSF Sampler

1)      Screenshot displaying the use of the BSF Sampler using  ${__setProperty(storeid, ${storeid})}; for capturing the time. The website used is http://www.mail-archive.com/jmeter-user@jakarta.apache.org/info.html for displaying the value captured in one thread to the other thread.

Screenshot 1: Displaying the BSF Sampler capturing the time value using ${__setProperty(storetime, ${__time(HMS)})};

Screenshot 2: Displaying the time captured using ${__property(storetime)} in the other thread.

Screenshot3: Successful execution of the script displaying the time value captured in Thread2