Sorry about the poor clarification. I did not mean to imply
multiply JVMs. I have successfully used the JMeter so-called
distributed client/slave configuration in similar web app
tests. This means one master machine with the actual JMeter
Test Plan to be invoked and several (if possible) actual
hardware machines running the JMeter slave servers. JMeter
is very efficient in this manner as any type of actual
hardware will do (as opposed to a virtual machine). In my
test I had 2 aging and slow Linux boxes and 1 much faster
Windows XP box as slave servers. A slight config is needed
for each slave server and just double-click or command-line
run the jmeter-slave.bat or jmeter-slave.sh shell script
accordingly. I then ran the JMeter Test Plan from a single
Kubuntu laptop. I was able to get the target Java web
application to begin dropping transactions at about a 25
loop count (iterations). A 25 loop count equates to 75
tranactions with 1 second in between transaction start up
(ramp
time). The only caveat is you can only run 1 ThreadGroup
(1 user) per machine but you can adjust the loop count and
ramp up time (including 0 ramp time) as needed to attain a
good baseline metric. The test just described involved 5
machines: 1 JMeter master (Test Plan), 3 slave JMeter
servers and the remote or public target machine with the
running servlet container and web app as the target of the
test. This is as close to a real-time, real-world test with
disributed users as I can muster. The more slave server
machines that you can employ in the test the more the test
model becomes like the target public production system. It
is easy to get the JMeter slave server to run in the
background on most machines. So, ask your friends! If I get
time I will try to work out a good Pebble JMeter Test Plan.
HTH, David.
Simon Brown wrote ..
> Just to clarify, before anybody starts putting effort
into load
> testing Pebble across multiple load balanced boxes, etc
: Pebble isn't
> designed to be distributed across more than a single
JVM. I agree with
> the approach though, grab JMeter and hit a single
instance as hard as
> you can. 
>
> Cheers
> Simon
>
> On Feb 12, 2008 6:31 PM, David Brown <david davidwbrown.name> wrote:
> > Hello, I'm very happy with Pebble but I do not
have thousands of users. If I
> were to test Pebble I would get MC4J or JMeter and hit
it hard. The only problems
> I have had with JMeter is the multiple ThreadGroup
(multi-user emulation) has concurrency
> problems with more than 1 user. The work-around is to
use many client slave machines
> (as many as you can muster) and run one user per
machine in a loop. Example: 10
> machines (anything with a JRE) with your JMeter Test
Plan installed running a loop
> of 10 iterations with a 0 ramp time will give you 100
concurrent hits. The original
> author Peter Lin has done some very good groundwork on
performance testing and
> tuning (JVM Eden tuning, scaling etc.). You might want
to find Lin's PDF document
> on Performance testing. The following link has enough
info to keep you busy for
> a week:
> >
> > http://wiki.ap
ache.org/jakarta-jmeter/
> >
> > Anything you do like this will require multiple
Tomcat or JBoss instances with
> a load-balancer. According to P. Lin: the best
load-balancers are appliance types
> like: Cisco or Big IP.
> >
> > Also, load/stress testing may be possible using
the JMX upon whence MC4J is based
> but I have not gotten there yet.
> >
> > HTH.
> >
> > Timothy Mizas wrote ..
> >
> > > Hi,
> > > I'm looking into pebble 1.9 as a possible
blog solution and I'm curious to
> know
> > > how well it scales. Are there any
Universities or companies using pebble as
> a blog
> > > solution? How well does it work with a few
thousand users?
> > >
> > > Thanks,
> > > Tim Mizas
> > >
> > >
------------------------------------------------------------
-------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual
Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > >
_______________________________________________
> > > Pebble-user mailing list
> > > Pebble-userlists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/pebble-user
> >
> >
------------------------------------------------------------
-------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio
2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Pebble-user mailing list
> > Pebble-userlists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/pebble-user
> >
>
>
------------------------------------------------------------
-------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pebble-user mailing list
> Pebble-userlists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pebble-user
------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Pebble-user mailing list
Pebble-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pebble-user
|
