Your e-Business Quality Partner eValid™ -- Automated Web Quality Solution
Browser-Based, Client-Side, Functional Testing & Validation,
Load & Performance Tuning, Page Timing, Website Analysis,
and Rich Internet Application Monitoring.

eValid -- LoadTest Safe Multiple Playbacks
eValid Home

Summary
eValid LoadTest scripts have the capability to access the driver machine desk-top. Most playbacks don't need exclusive access to the desktop, but in some cases they do. In addition, some playbacks need not only exclusive access to the desktop but need some kind of playback synchronization.

To prevent loss of playback coherency between multiple independent playbacks requires that the script be engineered to be "load test safe". Doing this will assure that two [or more] simultaneous playbacks do not interfere with each other.

Screen Access Control
Loss of coherent operation between two [or more] simultaneously executing eValid playbacks usually occurs when a shared resource is not reserved for exclusive use by the eValid instance needing it.

An example -- the most common one -- is in conflicted use of the desk-top. There being only one desk-top available, if two eValid scripts, e.g. A.evs and B.evs, both need to click on a window on the desk-top it is important to prevent an incorrect interaction. What you want to avoid is having A's click arrive on B's window.

The best way to do this is to use the available eValid Lock and Unlock commands to bracket the actions that require exclusive desk-top access. The Lock and Unlock commands implement a mutual-exclusion (mutex) logic that: (1) allocates control of the desk-top after a Lock to the issuing playback; which, (2) prevents all other playbacks from issuing Lock commands; until, (3) after the owner of the locked screen issues the Unlock command.

In general the Lock and Unlock commands should be used sparingly. That is, these commands should bracket the smallest possible number of commands. The desktop timeline has to be shared among many processes and if the length of time of each process's exclusive access is excessive, there can be very little parallelism.

Additional Synchronization Control
Using Wait times to control synchronization is inherently unreliable, and this problem is particular acute in multiple-browser playbacks. For example, if there is a server-load dependent page download if the server load is heavy it is possible for an eValid script without synchronization to "play ahead" and lose coherence.

The solution is to arrange for a xySyncRect or a SyncOnText command to hold playback until a particular condition is achieved on the time-variable screen. To do this reliably requires exclusive access to the desk-top by the current script. This can be accomplished with the Lock and Unlock commands.

Sample Script Structure
While every situation is different and there are many variations in how a script would be structured, here is a typical pattern that is load test safe:

  
   # eValid commands before the synchronizing area.
   .
   .
   # Reserve the screen for exclusive use by this playback...
   Lock
   
   # Take the action that requires variable time...
   GotoLink 0 "URL" ""
   
   # Now, make sure the action is completed before continuing...
   xySyncRect 0 620 400 101 73 2455675
   .
   # Here are other commands that also require exclusive screen access...
   .
   
   # Release the screen for use by other playbacks...
   Unlock
   .
   .