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.
Woody
----- Original Message -----
From: "sebb" <[EMAIL PROTECTED]>
To: "JMeter Users List" <[email protected]>
Sent: Thursday, October 18, 2007 1:42 PM
Subject: Re: Merging results from multiple clients
On 18/10/2007, Woody Aichner <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
