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]
