Stover, Michael wrote:
>
>>Ok. Another option would be to save a reference to the file, and store
>>the binaries separately. Many times, it's the same binary, with
>>different response times. In that case, it doesn't make sense to store
>>1,000 copies of a 10k image if they are all the same. That would also
>>speed things up for you.
>
>
> That'd be great, but there's lots of difficulties. I can't depend on the
> server returning the same info, even if the requests are identical. Being a
> testing app and all, it wouldn't do to trust the server makes no
> mistakes.... And then, I'd have to first verify that this file I just
> retrieved is identical to the one I got earlier - and now we're deep into
> performance problems.
Those are good points.
>
> I think maybe a better option is to allow the user to turn off response data
> saving. Still, there are other performance issues with constantly
> converting long to string back to long, and I may still want to delay
> storing data as attributes until serialization.
Exactly. Response data should really be as simple as you can make it.
JMeter began as a tool to _stress_ the webapp server. In that role, it
functions well. It is also very useful to have performance data to view
trends. It performs that role well.
However, when we save the actual results, we run into some additional
issues:
1) JMeter becomes an automated test validation tool. This is beyond the
original scope, and has a different set of requirements.
2) The amount of data the app needs to save is huge. You can only
optimize so much.
Correctness validation should not be concerned with performance, but
with correctness. Adding the correctness validation under load becomes
troublesome. In that case, you need a couple of JMeter instances that
merely bombard the server with unnecessary requests to add load--and pay
attention to whether the app breaks under that load.
We can't really rely on the absolute timing of the requests because
there are a number of issues that mess with that value--making it only
good to measure relative changes in performance.
Perhaps, JMeter needs to deal with two types of data.
1) Simple timing information, or statistic gathering information.
2) More detailed content information.
That way the simple timing information can be optimized--and if it does
not need the more detailed content the content is not created.
I still think that the COnfiguration object isn't the best sample
result object.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
