[prev in list] [next in list] [prev in thread] [next in thread]
List: jmeter-user
Subject: RE: 'Spread' for distributed testing
From: "Sonam Chauhan" <sonam.chauhan () ce ! com ! au>
Date: 2007-11-23 7:53:53
Message-ID: E5D178BFB0356B48A48B8330B2903721037E0A0E () syd1exc04 ! CE ! CORP
[Download RAW message or body]
Oops sorry... the attached thread from the spread list did not come
through, so here's a link to it:
http://article.gmane.org/gmane.network.spread.user/2818
Thanks again Sebb for all your help!
Best regards,
Sonam Chauhan
--
Corporate Express Australia Ltd.
Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
-----Original Message-----
From: Sonam Chauhan [mailto:sonam.chauhan@ce.com.au]
Sent: Friday, 23 November 2007 6:45 PM
To: JMeter Users List
Subject: RE: 'Spread' for distributed testing
Hi again Sebb... This is an older thread? Anyway, I had a good
discussion about this issue on the Spread list (email attached).
The approach suggested there was a second process (not JMeter) read the
JMeter disk logs and publishing them out the spread daemon in a
bandwidth limited manner. This neatly sidesteps the problems incorporate
the Spread protocol into JMeter, does not interfere with the length of
JMeter test runs, and also will not soak up network bandwidth.
> Ah - I see. That might help, but it would prolong the end of a test,
> as the queued entries must be allowed to filter through. There's also
> the question of where the queued entries are stored.
The cool thing is that the entries could be 'published' in a standard
format, to whichever application wanted to 'listen' to them -- these
could be log-unification tool, syslog, or a test results database where
test data could be sliced/diced at will.
Can you comment on how JMeter logs are written to disk? Is there
buffering involved, or does it write to disk as soon as it can?
Kind regards,
Sonam Chauhan
--
Corporate Express Australia Ltd.
Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
-----Original Message-----
From: sebb [mailto:sebbaz@gmail.com]
Sent: Monday, 12 November 2007 7:37 PM
To: JMeter Users List
Subject: Re: 'Spread' for distributed testing
On 12/11/2007, Sonam Chauhan <sonam.chauhan@ce.com.au> wrote:
> Sebb:
>
> > It's mainly a problem because of the data volumes that are required.
I
> > don't see how changing the transport mechanism can change that.
>
> I thought Spread had bandwidth throttling features so that logs
entries
> could queue up and stream in a bandwidth limited manner to the end
> destination - however Spread may not have these features. A workaround
Ah - I see. That might help, but it would prolong the end of a test,
as the queued entries must be allowed to filter through. There's also
the question of where the queued entries are stored.
> would be to setup virtual network interfaces limited to, say, 10 Mbps
> and have the Spread components bind to those interfaces, but that may
be
> too much work.
It may also be a lot of work to incorporate the Spread protocol into
JMeter.
> In any case, I've asked the question on the Spread user
> list.
Thanks.
> > > Is it possible to prototype this idea using a BeanShell listener?
> >
> >
> > I think it would be difficult.
> >
> > Listeners are handled specially in client-server mode.
>
> Thanks.
>
> Kind regards,
> Sonam Chauhan
> --
> Corporate Express Australia Ltd.
> Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
>
> -----Original Message-----
> From: sebb [mailto:sebbaz@gmail.com]
> Sent: Friday, 9 November 2007 12:57 AM
> To: JMeter Users List
> Subject: Re: 'Spread' for distributed testing
>
> In 08/11/2007, Sonam Chauhan <sonam.chauhan@ce.com.au> wrote:
> > Just a thought - Would the 'Spread Toolkit' (http://www.spread.org/)
> be
> > useful in JMeter distributed testing?
> >
> >
> >
> > From the Spread website:
> >
> > Spread functions as a unified message bus for distributed
> applications,
> > and provides highly tuned application-level multicast, group
> > communication, and point to point support.
> >
> >
> >
> > From what I understand, an existing problem in JMeter distributed
> > testing is collating logs back to the master server, particularly
when
> > the logs capture extra information (e.g., the HTTP response).
Perhaps
> > using Spread could help in this? It has a Java API encapsulated in
one
> > package.
> >
>
> It's mainly a problem because of the data volumes that are required. I
> don't see how changing the transport mechanism can change that.
>
> >
> > Is it possible to prototype this idea using a BeanShell listener?
> >
>
> I think it would be difficult.
>
> Listeners are handled specially in client-server mode.
>
> >
> > Kind regards,
>
> Thanks anyway.
>
> > Sonam Chauhan
> >
> > --
> >
> > Corporate Express Australia Ltd.
> >
> > Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
> >
> >
> >
> > Spread Toolkit
> >
> > http://www.spread.org/
> >
> >
> >
> > Java Interface to the Spread Toolkit
> >
> > http://www.spread.org/docs/javadocs/java.html
> >
> >
> >
> > An interesting article on using Spread to unify apache access logs.
> >
> > http://www.samag.com/documents/s=7789/sam0302a/0302a.htm
> >
> >
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic