|
|
| Synopsis: eVlite plays back eValid scripts with reduced fidelity using HTTP protocol only. Browser playback context is not preserved because the playback is not done with the eValid browser. The eVlite HTTP based protocol test engine can impose very high "navigational workloads" of Virtual Users (VUs) on the server. A single eVlite instance can simulate up to 1,000 VUs. Thirty eVlite instances running on a 3 GB machine simulate the activity of 30,000 VUs. |
Introduction
eVlite is an alternative eValid playback engine that
plays back any eValid script with limited fidelity.
We call this kind of limited-fidelity, non-context-preserving,
playback a Virtual User (VU).
Such a playback will seem to be a real user to the server,
the playback does some activity-producing work,
but it is NOT the same total effect as a full-fidelity,
full-eValid Browser User (BU).
eVlite is capable of playing back a script in a single or in multiple threads. There can be up to 1,000 threads -- one for each VU -- all running the same script. In addition, each eVlite instance can repeat the playbacks for each thread any number of times. This means that a single eVlite instance can simulate continuous VU activity of up to 1,000 users.
Running eVlite
eVlite is launched only from a LoadTest script.
You switch the LoadType mode from FULL or TEXT
to the eVlite mode: LITE.
Each line in the LoadTest script implies one eValid or one eVlite. You can switch between the two in any combination based on your scenario requirements.
URL Trace Output
You may wish to generate a special
URL Trace File to diversify the sequence of URLs that your
eVlite instance will download.
The automatically generated URL trace file will have GetURLs for each
page component navigated to by eValid.
Recommended Usage
eVlite is very good at creating
a very large amount of activity on a server.
Running eVlite with 1,000 VUs usually will consume a major part of
available server capacity.
However, remember that this activity is non-coherent, non-context-preserving activity.
These are VUs -- not BUs.
We have found from experience that using eVlite to create significant non-transaction activity makes it easier to identify the break points in overall response time for transaction activity, that is, for full-eValid playbacks. A good ratio between the two modes is 10 BUs to each 1,000 VUs.
Size and Capacity
The table below shows some typical values for number of VUs vs. footprint vs. total capacity,
assuming an eValid driver computer with ~3 GB RAM total,
with ~1,999 MB available for eVlite executions.
| Runtime Properties of Various Combinations of eVlite | ||||||
| Number of Users Per eVlite Instance | 1 | 10 | 50 | 100 | 500 | 1,000 |
| Maximum Number of eVlite Instances | ~100 | ~100 | ~90 | ~85 | ~50 | ~30 |
| eVlite Total RAM Footprint All eVlite Instances | ~8 MB | ~8.5 MB | ~9.6 MB | ~11 MB | ~25 MB | ~42 MB |
| Achieved Total Number of Virtual Users (VUs) | ~100 | ~1,000 | ~4,500 | ~8,500 | ~25,000 | ~30,000 |
Playback Commands Recognized
eVlite recognizes a limited number of eValid commands, listed below.
All other eValid commands in a script are read but are
not processed by eVlite.
|
Performance Reporting
eVlite reports data to the LoadTest logfiles just as eValid does.
All data from any single eVlite invocation,
regardless of the number of threads, uses only one LoadTest ID.
