> Check out the Aggregate Report. It gives you this data per different request. I >use it to > pinpoint which requests are giving all the trouble - time wise and error-wise. It >could use > enhancement, but it's quite useful as it is. >
Hups. Haven't seen it yet. That's the really good. > > 2. Maybe it could be useful (could it?) to set up a timer or something > > else to ensure that with a given number of users your throughput is met. > > That is you set up the ThreadGroup as usual. But you add something where > > you can input the throughput you want to guarantee. If you run your > > tests you will receive a failure if the throughput cannot be met or a > > value indicating how much sleep-time remains between individual requests > > per user. This one might be helpful in determining if addition to a > > given path. E.g.: I have contributed to a web-app where the user had to > > follow a given path to get a map in the end [which is the most > > time-consuming page of course]. So if I want to add some steps and some > > processing in between, could we probably meet the throughput-goal or > > not. Yet I'm not so sure about that (especially since I guess it would > > be some work to realize it). Hm, after thinking a short while about > > this, I think one would get the result as quickly by the exiting > > GraphVisualizer. But maybe my confused thoughts elicit better and more > > useful thoughts by others... > > Sounds similar to thoughts I'd had about making JMeter adjust test settings to >discover various > things about a site. For instance, gradually increasing the number of threads to >find the > saturation point of the server. Similarly, decreasing the delays could be part of >that, and > Jordi's throughput timer idea is probably most useful in that respect. > Maybe I will put a bit more thought on it, since I (at least for now) completed my work on the DurationAssertionGui and the MailerVisualizer - see my other mail in a few minutes. BTW: It's a nuisance to enter mail-addresses and server and so on every time the MailerVisualizer is needed. But Visualizers are not saveable. Correct? So what could I do, to change this? That's not a thing that is relevant to other visualizers since they do not contain user-entered values. But the MailerVisualizer does. Another way to ease this would be, to get the values from a property-file. Not as good and comfortable as saving, but still a lot better than typing in. So long, Wolfram -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
