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

Introduction
These are supplemental advisories about eValid when used in Load Testing Mode. This information is presented in outline form and is intended for backup to experienced eValid users. These comments and suggestions are "raw" data; contact eValid technical support for details.

Reference Pages
These are the main eValid documentation reference pages that concern LoadTest operations:

• Machine Adjustments -- The basic instructions on how to get the most out of your CPU by making OS adjustments.
• LoadTest Usage Hints -- Includes additional material concerning such issues as heap settings and VM settings.
• Machine Capacity Notes -- Includes additional suggestions to maximize eValid performance.
• Load Test Safe Multiple Playbacks -- How to make sure a functional test is ready to be lifted into load test mode.
• Load Test Settings -- All of the eValid settings that apply to Load Testing.
• Lock/Unlock Command -- The syntax and use of the Lock and Unlock commands.
• Merging LoadTest Logs -- Merging & consolidating the logs from multiple machine runs.
• Load Testing Settings [including Re-Spawn Option] -- The settings that apply to load testing, including the setting that controls how often to re-spawn eValid during long load test runs.
• Wait Commands -- These commands provide a way to synchronize scripts on one machine or between multiple machines.

Background Facts & General Advice

• RAM Issues.
  The amount of RAM is the main limit to multiple eValid playbacks. How much RAM do you have. 512 MBytes usually allows 50+ eValids. 1,024 MBytes usually allows 100+ eValids.

  Use the Windows Task Manager to monitor how much RAM you are using. If you start using virtual memory you are probably over your internal limits.

  It is a good practice to monitor RAM usage by eValid copies to make sure you don't fall into the "disk thrashing" mode. You may also want to consider deleting other tasks that could interfere with eValid playbacks.

• eValid Launch Rate.
  The default scenario editor setting for the eValid LoadTest interval between launches (execution of _eValid commands) is 1000 msec (1 sec). This default value is nominal, but give the operating system time to "relax" before doing a subsequent lanuch.

  The wait time at the eValid LoadTest lanuch level is governed by the Wait Time Multiplier in the settings. To prevent overloading the operating system sometimes it makes sense to use Delay 1000> commands (which are NOT affected by the Wait Time Multiplier.

• eValid Size Growth.
  As eValid runs it grows in total footprint; eValid grows more slowly than IE does. The eValid THIN playback version starts at a lower RAM requirement, but it also grows. You can watch this using the Windows Task Manager.

  You may want to consider setting a re-spawn interval of 10 or even 5 if you see excessive RAM growth.

• eValid Load Type, Serve Type.
  If you see you are running out of RAM, you may want to switch to LoadType THIN. You probably don't want to switch to serve type TEXT or URL unless you can afford to sacrifice eValid's playback reality.

• Cache Issues.
  The cache on your PC is a shared resource -- all eValid instances use the same cache. Accordingly, all eValid LoadTest runs all operate with "no cache." This may introduce some additional work on the part of the server, but the eValid perspective is that this is a conservative assumption.

• Desktop Issues.
  Avoid desk top tests if possible. The desktop has to be shared and if you have scripts where each require N% of the time line, then you are effectively limited to 1/N total parallel scripts. Example, a script that takes 10 seconds out of 100 seconds elapsed time implies a limit of 100/10 = 10 parallel playbacks.

  Similarly, if the desktop duty cycle is 1% then you can at most have 100 parallel playbacks before the overall utilization exceeds 100%. You need to experiment to make sure you get the right numbers.

  To test if a script is load test safe you should try to run the test with Minimize command. If that works you're OK.

• Screen-Based Synchronization.
  All screen-based syncs should be avoided; remember, the desktop time line can only be divided so many ways.

  The synchronize on text or URL commands, SyncOnText, SyncOnURL, are OK to use because they can run OK with eValid minimized; there is no desktop activity needed.

  But in most cases a synchronization step that uses a desktop image with the xySyncRec command requires lengthy exclusive use of the desktop. You'll have to Lock/Unlock around that and that process may limit the total number of copies of eValid that can run simultaneously. You can only divide the desktop time line up so many ways!

• Multi-Machine Synchronization.
  When running 2 or more machines consider using WaitModMM commands in your script as a way to simultaneously start scripts at a particular time.

• Server Performance Checking.
  To read performance from the server(s) we recommend use of the performance measurement engine that is available on the server.

  We recommend RDC direct to the IIS server, or VNC [or Telnet or an equivalent connection protocol] to a UNIX server where perfmon is a possible choice.

• Open Minimized.
  To minimize clutter on the screen you may want to consider use of the - Minimize switch to cause the child browsers all to open minimized. This is a good practice ONLY after you have confidence that the script being processed by eValid will work withOUT requiring desktop access (i.e. LoadTest "safe").

• Interaction With LoadTest Timeout Value.
  The LoadTest Timeout Value, one of the LoadTest settings, is a safety mechanism that prevents LoadTest runs from consuming excess machine resources. This feature will cause all load testing activity to cease as soon as any of the launched eValid browsers exceeds the maximum time specified.

  The LoadTest Timeout value should be set to be LONGER than the anticipate total playback time to avoid an unanticipated "LoadTest Timeout" effect and message.