Cookies - How loops affect the state of virtual users

+

Search Tips   |   Advanced Search

Overview

By default, the cookie cache for a virtual user is not reset during a test run. If a test or schedule contains loops, and a Web server sets a cookie during the first iteration of the loop, that cookie is "remembered" on subsequent iterations.

This is consistent with a browser's behavior and the actions of users in the real world, where users rarely log out by using the logout button. Rather, they let the browser sit idle until their session times out.

To have each iteration of a loop to appear as a new user, reset the cache.

Typically, a lot of sessions in memory are waiting for cleanup pending the WAS session timeout, increasing the JVM heap working set and the probability of heap exhaustion.

Effective simulations must model this behavior of users who do not explicitly log out. As each individual simulation executes a particular use case, it should end the use case by going idle as opposed to logging out.

As the script cycles back around to log in a new user on this particular virtual user, the cookies for JSESSIONID and LTPA, along with any application-specific cookies need, need to be cleaned up before logging in the next user using that script.

This model also implies that sufficient test IDs need to exist so that a test ID can sit idle for the length of the WAS session timeout without risk of being reused until the previous session times out.

Reset cookie caches when...

• Looping in a schedule
• Test follow other tests in a schedule
• You are running back-to-back tests
• You are running Siebel tests

Procedure to reset the cookie cache

1. Double-click a test

2. On the HTTP options page, select...
   Clear cookie cache when the test starts

   

Reset cookie cache with custom code

To reset the cookie cache from one loop iteration to the next when you have put a loop around the entire contents of the test, and the loop is inside the test, add custom code to the test and call an API, as follows:

1. Run the test or schedule to add the current Java libraries to the class path.

2. Open the test and select the test element located at the point where you want the cookie cache to be reset. Typically, this is at the end of the loop.

3. Click Add or Insert and select Custom Code.

   

   Add appends the custom code to the bottom of the selected element (test or test page). Insert adds the custom code above the selected page or page request.

4. Add the following Java import statement:
   import com.ibm.rational.test.lt.execution.http.util.CookieCacheUtil;

5. Add the following Java code inside the exec method:
   CookieCacheUtil.clearCookieCache(tes);

6. After saving you should see custom code reference in the Test Contents panel.

   

Custom Code Example

Add the bolded lines to the generated custom code template...

package test;

import com.ibm.rational.test.lt.execution.http.util.CookieCacheUtil;
import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;

public class Class1131739398417 implements 
     com.ibm.rational.test.lt.kernel.custom.ICustomCode2 
{
  public Class1131739398417() 
  {
  }

  public String exec(ITestExecutionServices tes, String[] args) 
  {
    CookieCacheUtil.clearCookieCache(tes);
    return null;
  }
}

See also: custom code that sets and clears cookies

Related

1. HTTP test editor overview
2. Define performance requirements in tests
3. Add an authentication folder
4. Verify expected behavior
5. Split a test
6. Split a test page
7. Merge test pages
8. Disable and enable secondary HTTP requests
9. Reuse tests on different hosts: Server connection variables
10. View a test in the Protocol Data view
11. Test Siebel applications
12. Run tests at a set rate
13. Repeat tests in a schedule
14. Add a loop to a test