|
|
Summary
These notes provide additional information to advanced eValid users
who are performing intensive WebSite monitoring.
Certain limits regarding cache management, multi-tracking, lock management, time-line
budgeting, and desktop focus contention are discussed.
Cache Management
There is only one cache area on Windows NT/2000/XP/Vista.
When running two or more copies of eValid it is important to understand that the best
results are obtained when all copies of eValid operate with "No Cache".
If one copy of eValid is running with no cache, and a second copy is running with "Delete Cache Before Playback" it is likely that the first copy will eliminate some of the copies of URLs that are supposed to be present for the second copy.
Multi-Track Monitoring Approach
eValid is a superb WebSite monitoring engine because it operates in real time and with real
website downloads you
may need to remember that there are only 3600 available seconds in each hour.
A 10-track monitoring scheme on one machine -- our recommended width -- leaves
effectively only 360 seconds per track per hour.
If one of the 10 tracks starts a 36 second playback sequence 10 times an hour there
will be no left over wait time.
Accordingly, it is imperative to perform a careful time-line check
when running multiple eValid monitoring tracks on a continuous basis.
Desktop Focus
There is only one desktop on Windows NT/2000/XP/Vista.
When two [or more] copies of eValid may compete for access to the desktop it is
important to bracket critical areas of the script with Lock ... Unlock commands.
This command reserves the focus on the desktop to the eValid copy which first requests it.
Remember, the operating system response is not instantaneous do it may be a good idea
to put a "Wait 100" after a Focus command to make sure that the window really IS in focus.
Even better is to do a sync on some text or property of the window.
Focus Lockout
When one copy of eValid executes the Unlock command all other copies of eValid that
are in a wait loop pending receiving a Lock are served on an as-available basis that is
determined by the operating system system and not determined by eValid.
When there are many eValid processes competing
for a Lock to take effect there is a slight chance that one of them may never achieve
a Lock because of operating system priorities.
Although such exclusion is a theoretical possibility,
our experiments have shown that this does not happen
with up ~100 parallel pending Lock requests in very tight loops.
Cache Lockout
There is only one cache on Windows NT/2000/XP/Vista.
When two [or more] copies of eValid are running they share the cache -- just as would
two [or more] copies of IE.
If you are taking detailed timings from navigation commands, each copy of eValid needs to have
exclusive access to the cache in order to determine final element download times.
In this case you may wish to
bracket parts of the script for which accurate download times are required with Lock ... Unlock commands.
Running eValid Minimized
Even though playback will proceed normally when running in a minimized eValid browser
some test operations require restoring the browser to a specific size.
If you have several of these competing for screen space there can be conflicts
unless you use the Lock ... Unlock mechanism.
