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 -- Supplemental Operational/Advisory Comments for LoadTest
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.
These are the main eValid documentation reference pages that concern LoadTest operations:
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,
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
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.