[Martin]

Hi,

I'm seeing response times that are longer than the time the test has been running for. (Eg 61 hours when the test only runs for 2 hours).

Naturally this skews the results significantly.

I am running WAPT 5.0

Thanks
Martin

[angela]

Hi Martin,

It seems that you need to disable the option “Stop test correctly” in Settings.

If this option is turned on, the test will be stopped "correctly". It means that if the time of test run is over, all running user sessions are executed to the end of their profiles. Only after that the test completes. This is useful if you do not want to leave many open sessions on your server after the test. However, such sessions do not participate in test run statistics.

[Martin]

Hi Angela,

Thanks for the reply.

I will try that next time I run the load test.

I have to say, I don't see why that should fix this. Under no circumstances should the time to respond be longer than the test has been running for - how could it?

For what it's worth, I don't think the "stop test correctly" is well explained. It would be useful to give a scenario where it needs to be on.

Martin

[angela]

I have to say, I don't see why that should fix this. Under no circumstances should the time to respond be longer than the test has been running for - how could it?

For what it's worth, I don't think the "stop test correctly" is well explained. It would be useful to give a scenario where it needs to be on.

Martin

Hi Martin,

I will try to provide an example which, possibly, will explain the reason for using this option more clearly.

In general, such option can be used in tests which deal with transactions, i.e. sequences of users' actions. For instance, in case of registration with confirmation. If this option is not selected, some users can have enough time to register but fail to confirm their registration due to lack of time.

As for your test case, we suggest that you enable logging in WAPT and generate full and error logs: you will be able to see what makes the test last so long time. If you send the logs to support@loadtestingtool.com, we will be happy to assist you.

[angela]

Hi Martin,

I will try to provide an example which, possibly, will explain the reason for using this option more clearly.

In general, such option can be used in tests which deal with transactions, i.e. sequences of users' actions. For instance, in case of registration with confirmation. If this option is not selected, some users can have enough time to register but fail to confirm their registration due to lack of time.

As for your test case, we suggest that you enable logging in WAPT and generate full and error logs: you will be able to see what makes the test last so long time. If you send the logs to support@loadtestingtool.com, we will be happy to assist you.

Hi,
We suspect a serious bug there, and now we are conducting some testing. So let's wait for a couple of days for the first results. Sorry for the inconvenience, we will try to fix it as soon as possible.

[David]

Hi,
We suspect a serious bug there, and now we are conducting some testing. So let's wait for a couple of days for the first results. Sorry for the inconvenience, we will try to fix it as soon as possible.

I haven't been able to find any followup on this issue. I also see inaccurate Response Times interspersed with otherwise expected results. Values such as 4,294,967 are repeated. I have tried extending think times and disabling them. I am not receiving any errors. What's the status of this issue? I will contact Support as well.

Thanks,
David

[angela]

I haven't been able to find any followup on this issue. I also see inaccurate Response Times interspersed with otherwise expected results. Values such as 4,294,967 are repeated. I have tried extending think times and disabling them. I am not receiving any errors. What's the status of this issue? I will contact Support as well.

Thanks,
David

Hello David,

Please try the latest build from our site (September 26, 2008) and let me know if the problem remains there.

[David]

Hello David,

Please try the latest build from our site (September 26, 2008) and let me know if the problem remains there.

Hi Angela,

I installed the latest version as you suggested. I do see fewer incorrect response times, and now the incorrect value is always the same: 2,147,484. I've only executed a handful of tests, so I'll keep trying. Currently I have think time disabled, so I'll try changing that. Otherwise, I'm open to suggestion, and would be happy to zip up the scenario, profile, log, and results files and send them to you/support, if that would help.

Thanks,
David

[David]

Hi Angela,

I installed the latest version as you suggested. I do see fewer incorrect response times, and now the incorrect value is always the same: 2,147,484. I've only executed a handful of tests, so I'll keep trying. Currently I have think time disabled, so I'll try changing that. Otherwise, I'm open to suggestion, and would be happy to zip up the scenario, profile, log, and results files and send them to you/support, if that would help.

Thanks,
David

Hi again Angela,

I continue to see occasional large max response times: 2,147,484 and 4,294,967. I will send logs to Support.

Thanks,
David

[David]

Hi again Angela,

I continue to see occasional large max response times: 2,147,484 and 4,294,967. I will send logs to Support.

Thanks,
David

I still see these aberrations with response time. I haven't sent logs because they may contain sensitive data, but I am curious if you've investigated this?

Thanks,
David

Attached File(s)

•  response_times.JPG (32.98K)
  Number of downloads: 19