jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Merging results from multiple clients
Date Thu, 18 Oct 2007 23:30:38 GMT
On 18/10/2007, Woody Aichner <waichner@nc.rr.com> wrote:
> OK --- thank you for the response. that was helpful. Since that post, I have
> found out that the test crashed the site in such a way that all the Jmeter
> threads (users) are waiting.
>
> I will try and execute in batch mode with a single results file. The only
> thing about this mode is that it is unlike the GUI mode where it is obvious
> that no samples are being returned, because the Summary Report stops
> updating.
>
> I suppose I could tail the results file.

There is a summariser just for this purpose - check the summariser.*
properties in jmeter.properties

> Woody
>
>
> ----- Original Message -----
> From: "sebb" <sebbaz@gmail.com>
> To: "JMeter Users List" <jmeter-user@jakarta.apache.org>
> Sent: Thursday, October 18, 2007 1:42 PM
> Subject: Re: Merging results from multiple clients
>
>
> > On 18/10/2007, Woody Aichner <waichner@nc.rr.com> wrote:
> >> I think that to be able to stress the target system to its maximum, I
> >> will need to execute on more than one client system as the overhead of a
> >> large number of
> >> threads seems to affect the client system and skews the results. That is
> >> my observation, which I have tried to validate, restarting the system and
> >> executing another test. As I continue to execute tests, I notice the
> >> response times degrade. I only notice this will a large number of threads
> >> (50). I am running my client on a home network (100Mb), cable modem and
> >> executing against a system in a remote location.
> >
> > 50 threads is not a large number, unless the threads are very intensive.
> >
> > See for example a recent thread entitled: "Open threads limit"
> >
> > JMeter should be able to handle quite a lot more than 50 threads.
> >
> >
> >> I have seen this discussed before. I also am aware of third party
> >> performance testing tools that collect the results to the master from the
> >> slaves after the test
> >> has completed.
> >>
> >> What I wanted to do is to start a thread on approaches to this and also
> >> whether it would be a desired extension to Jmeter that would allow the
> >> merging of results from the slave systems, after the test has been
> >> completed. It seems to me that this is not possible now and is only
> >> supported real time or in "batches". Perhaps the batch size can be
> >> configured such that all the results are sent upon completion of the
> >> test. It seems to me an approach like this is desirable to relieve the
> >> network of the overhead of sending the results to the master during the
> >> test.
> >
> > There sampling mode "Hold" saves the results and sends them at the
> > end, but this requires lots of memory.
> >
> > There is also a Statistical mode but this loses all the details of the
> > individual samples.
> >
> > Neither of these is ideal.
> >
> >> So one approach that I saw was to merge the results based on timestamps
> >> in the results file.
> >
> > Note that the timestamps may be out of order even in a single file,
> > because they are start times. Even when using end-times, they may be
> > out of order when multiple remote servers are used.
> >
> > I don't think any of the current Listeners care much if the results
> > are not exactly in order.
> >
> >> I am guessing that this is a simple matter if the results are in CSV
> >> format, but somewhat more complex in XML format. I like that the XML
> >> format because of the jmeter extras reporting that uses xslt to transform
> >> the xml results to HTML.
> >
> > CSV is fairly trivial to merge - just concatenate and sort the file,
> > dropping the duplicate headers.
> >
> > I expect XML would be quite a bit harder.
> >
> > Also XML is more expensive at run-time.
> >
> > For minimum resource usage, JMeter should be run in stand-alone
> > non-GUI mode with a single results output file. So I'm not yet
> > convinced that it would be useful.
> >
> >> Woody
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message