The tests we were running on Friday have been completed. We do have a question
about how the eValid browser reacts with the IE base version it is running on.

We know that eValid is running as its own browser for the tests. However,
we ran the same test on 3 different boxes, each with a different IE version
(6, 7, 8) . With the test- about 120 minutes in length, all 3 finished within
about 20 seconds of each other.

This wasn't completely unexpected, but we did expect the IE8 test to be the
fastest and it was not. I have looked at the documentation and have not
found any specific information addressing the browser version difference. If
it is included, can you please send me the link to its location?

Or, does the IE version not matter, and the tests are completely dependent
on the eValid browser code and independent of the IE version.

Thanks.

Thanks for asking. Interesting data and an interesting suggestion.

As you know, eValid uses the underlying version of the IE rendering engine
to handle the actual work of obtaining and rendering each page.

We have not noted any particular speed advantage of any of the three
IE's you mention: IE 6, IE 7, or IE 8. IE 8 is generally less buggy,
but not measurable faster -- as far as we can tell.

If you have tests that each take 120 minutes = 7200 seconds, and the
variation in total playback time was 20 seconds, that is 0.277% difference.

I would imagine that you would see that must difference in that long a
test just with the variation in the delivery order of all the packets
in the HTTP protocol.

It seems to me that it would be rather absurd to try to ascribe that
tiny, tiny difference to the IE version IE 6, or IE 7 or IE 8.

There are too many OTHER things going on during a test playback that
would more than swamp that small difference for your 20 second variation
alone to be significant of anything.

Just for your information, our continuing design goal for eValid is that the
total overhead of eValid is less than 0.1% -- or one part in 1,000.
So far as we know we have not exceed that...basically because the overhead
is so low as to be non-measurable in most instances.

Please remember that eValid is, at the end of the day, a windows process
and even if your windows machine is 0% busy -- and they almost never are
totally idle -- the 0.277% variation could be accounted for in just
the overhead of the operating system, file system activity, and a
thousand other factors.

So, I'd say that if IE 6, IE 7 and IE 8 all came in within 0.277% of
each other you have little to worry about.

Hope this helps...

Best Regards,

The IE version is as important as any part of testing our application. A
large number of our clients are on IE6. Therefore, we need to know of
performance differentiation due to browser version. (I am not even asking to test
on Firefox (18% of users) or Safari (4% of users).

When I was looking at the results from running the same eValid script on
all 3 browsers they were similar - it seemed wrong. I then manually went
through the same script and IE6 was noticeable slower than IE8.

I need to know why.

(1) Are you aware of eValid's ability to pretend being other
browsers? This lets eValid instruct the server to deliver the
HTML as if it was Safari or FF or Chrome or ??

* Here is an illustration of how effective eValid's SetUserAgent string
can be in testing applications that involve multiple browser types:

http://www.e-Valid.com/Products/Documentation.9/UserAgent/illustration.html

(2) We often observe that something seems to take a longer than
you expect... If you record something and you are saving the
wait times (real time recording) and they you play it back we
all find outselves saying, "no way, it didn't take me that long
to make that recording."

But the software doesn't lie...it really DID take that long.

It's a human perception thing.

(3) The key phrase is "...manually...IE 6...was noticeable slower"
but did you do a measurement for that? Again, you need to have
confidence in eValid...!

(4) In the case of IE 6, IE 7 and IE 8, did you uninstall
completely each time? For example, if a machine has IE 8 installed
and they you install IE 7 it could be that the installer doesn't
bother to replace DLLs that are already present... I'm suggesting
that you may think you have IE 6 but you might have the DLLs from
IE 8...

FWIW, we do know that the DLLs generally are named the same from
version to version, and they are 100% upward compatible. We don't
know if Microsoft has ever redacted something going backward, but
we doubt it.

As the prior email points out a 0.277% variation is very good...
unless you were expecting the times to be identical? You weren't
were you?

Best Regards,