On 21/09/2007, sebb <[EMAIL PROTECTED]> wrote: > On 21/09/2007, Christiaan Lamprecht <[EMAIL PROTECTED]> wrote: > > > If there are a lot of samples, this may just cause the servers to run > > > out of memory. > > > > > > Perhaps try Statistical. > > > > Works great! > > > > ./jmeter -n -r -t my_test.jmx -l log.jtl > > > > > > ... except that the results returned is always 0 for latency on the > > distributed test. (i.e. using -r) and I get proper latency results for > > the same non-distributed test. Elapsed Time is always ok. > > > > > > > > I did a 'diff' on the jmeter.properties for all the machines and they > > are all the same. > > > > Only the client one should matter, because that is where the samples are > saved. > > > > > jmeter.properties: > > > > (only "timestamp", "latency" and "elapsed" is 'true') > > > ... > > > > Sounds like a bug? Any suggestions? > > Yes, it's a bug - the latency is not collected currently.
Bug 43449 raised. > In fact there seem to be other omissions, e.g. the success/fail flag > is not set, and the thread group name is not set. > > Also if one uses a Summary or Aggregate Report Listener, this seems to > use both the original and summary samples for its display, whereas the > Table/Tree view listeners only show the summary samples. (This is when > using a GUI client). > > Not sure how easy it will be to fix. It was quite easy, so it's been fixed. But there are still some issues related to it - the sample results files does not show the sample count. > Might be worth trying one of the other modes. > > No need to have *any* Listeners in the test plan when running non-GUI. > The -l flag will add one for you. > > S/// > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
