postany wrote:From what we understand, your server loading capability relies on using an empty cache all the time, is that correct. My question is, what is the impact of this on the "reality" of the playbacks (tests)?
You have a good point.
The Windows environment has two unitary resources that are of concern if you are driving applications with multiple browser: (1) the desktop face, and (2) the cache.
For most load tests that we do -- particularly those which are heavily AJAX -- we can organize the tests so that they do not need the desktop at all. We call that "desktop safe" and you can imagine this as a test that runs perfectly well in a browser even when the browser is mimized. So (1) is handled.
The cache is slightly different, because what we do is simply have every test that is running run withOUT the cache. That means that when a page is downloaded, and the eValid browser sees that it is complete, then eValid flushes that page from the cache.
This means that (a) if the page is used a second time in the script --later on in the playback -- it will have to be 100% reloaded [because it was already deleted], and (b) now two eValid's will become confused by the fact that one instance wants a page an, oops, it's already there because another instance just loaded it.
So the "never use cache" assumption really has just the one issue, in that a second reference to a page in any particular playback initiates a whole new download. So in this case, the eValid playback works a little bit harder than the real user would have done -- this makes the load imposed by eValid a little bit greater than without this assumption -- but we view this as a conservative assumption that doesn't affect the overall outcome.
The eValid Team