You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Michael Stover <ms...@apache.org> on 2004/06/18 01:54:08 UTC

using xstream to save .jmx files

I recently experimented with replacing JMeter save/load code with
xstream's java xml serialization code.  I'm wondering how people feel
about it.

The advantage is the code is 100% simpler.  5 lines of code replace the
hundreds currently living in SaveService.

The disadvantage is that, without customization, the xstream version of
the files are 3-4x larger.  Speed, however, appears unchanged.

On my local system, JMeter can load both previous versions and xstream
versions, so that's not an issue.  Also, I would include file versioning
with it so that a test plan file would include the jmeter version that
made it.  This would help in the future with backwards compatibility.

I personally like it, but then, a file going from 100k to 400k is no big
deal to me - I don't save 10000 objects in my test plans (100 and 400
are the relative sizes of the guitest.jmx file)

Any opinions?

-- 
Michael Stover <ms...@apache.org>
Apache Software Foundation


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org


Re: using xstream to save .jmx files

Posted by peter lin <jm...@yahoo.com>.
I've been using XStream and I really the simplicity of
the API. it's also very fast.  


peter

--- Michael Stover <ms...@apache.org> wrote:
> As far as log format, I didn't put it in for that. 
> Making new
> converters looks pretty easy, and I think making
> some for the
> JMeterProperties, and HashTree could help greatly
> with file size.
> 
> Making one for SampleResults would be very simple.
> 
> -Mike
> 
> On Thu, 2004-06-17 at 20:32, Sebastian Bazley wrote:
> > Would this change the log file format as well?
> > There may well be utilities that depend on the
> current format (e.g. the Ant
> > utility in /extras)
> > Also, having larger log files would definitely be
> a problem.
> > 
> > We don't use large test plans (yet ...) so an
> increase in the size of these
> > is not a big deal.
> > If they are easier to read that would be useful,
> as it might avoid having to
> > launch JMeter just to find out what the plan is
> doing..
> > 
> > Can you perhaps post some samples to show what
> they look like? (perhaps on
> > the Wiki, to save bandwidth here).
> > 
> > Also, what about UTF characters? Are these handled
> OK?.
> > 
> > S
> > ----- Original Message ----- 
> > From: "Michael Stover" <ms...@apache.org>
> > To: <jm...@jakarta.apache.org>
> > Sent: Friday, June 18, 2004 12:54 AM
> > Subject: using xstream to save .jmx files
> > 
> > 
> > I recently experimented with replacing JMeter
> save/load code with
> > xstream's java xml serialization code.  I'm
> wondering how people feel
> > about it.
> > 
> > The advantage is the code is 100% simpler.  5
> lines of code replace the
> > hundreds currently living in SaveService.
> > 
> > The disadvantage is that, without customization,
> the xstream version of
> > the files are 3-4x larger.  Speed, however,
> appears unchanged.
> > 
> > On my local system, JMeter can load both previous
> versions and xstream
> > versions, so that's not an issue.  Also, I would
> include file versioning
> > with it so that a test plan file would include the
> jmeter version that
> > made it.  This would help in the future with
> backwards compatibility.
> > 
> > I personally like it, but then, a file going from
> 100k to 400k is no big
> > deal to me - I don't save 10000 objects in my test
> plans (100 and 400
> > are the relative sizes of the guitest.jmx file)
> > 
> > Any opinions?
> -- 
> Michael Stover <ms...@apache.org>
> Apache Software Foundation
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jmeter-dev-help@jakarta.apache.org
> 
> 



	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org


Re: using xstream to save .jmx files

Posted by Michael Stover <ms...@apache.org>.
As far as log format, I didn't put it in for that.  Making new
converters looks pretty easy, and I think making some for the
JMeterProperties, and HashTree could help greatly with file size.

Making one for SampleResults would be very simple.

-Mike

On Thu, 2004-06-17 at 20:32, Sebastian Bazley wrote:
> Would this change the log file format as well?
> There may well be utilities that depend on the current format (e.g. the Ant
> utility in /extras)
> Also, having larger log files would definitely be a problem.
> 
> We don't use large test plans (yet ...) so an increase in the size of these
> is not a big deal.
> If they are easier to read that would be useful, as it might avoid having to
> launch JMeter just to find out what the plan is doing..
> 
> Can you perhaps post some samples to show what they look like? (perhaps on
> the Wiki, to save bandwidth here).
> 
> Also, what about UTF characters? Are these handled OK?.
> 
> S
> ----- Original Message ----- 
> From: "Michael Stover" <ms...@apache.org>
> To: <jm...@jakarta.apache.org>
> Sent: Friday, June 18, 2004 12:54 AM
> Subject: using xstream to save .jmx files
> 
> 
> I recently experimented with replacing JMeter save/load code with
> xstream's java xml serialization code.  I'm wondering how people feel
> about it.
> 
> The advantage is the code is 100% simpler.  5 lines of code replace the
> hundreds currently living in SaveService.
> 
> The disadvantage is that, without customization, the xstream version of
> the files are 3-4x larger.  Speed, however, appears unchanged.
> 
> On my local system, JMeter can load both previous versions and xstream
> versions, so that's not an issue.  Also, I would include file versioning
> with it so that a test plan file would include the jmeter version that
> made it.  This would help in the future with backwards compatibility.
> 
> I personally like it, but then, a file going from 100k to 400k is no big
> deal to me - I don't save 10000 objects in my test plans (100 and 400
> are the relative sizes of the guitest.jmx file)
> 
> Any opinions?
-- 
Michael Stover <ms...@apache.org>
Apache Software Foundation


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org


Re: using xstream to save .jmx files

Posted by Sebastian Bazley <se...@apache.org>.
Would this change the log file format as well?
There may well be utilities that depend on the current format (e.g. the Ant
utility in /extras)
Also, having larger log files would definitely be a problem.

We don't use large test plans (yet ...) so an increase in the size of these
is not a big deal.
If they are easier to read that would be useful, as it might avoid having to
launch JMeter just to find out what the plan is doing..

Can you perhaps post some samples to show what they look like? (perhaps on
the Wiki, to save bandwidth here).

Also, what about UTF characters? Are these handled OK?.

S
----- Original Message ----- 
From: "Michael Stover" <ms...@apache.org>
To: <jm...@jakarta.apache.org>
Sent: Friday, June 18, 2004 12:54 AM
Subject: using xstream to save .jmx files


I recently experimented with replacing JMeter save/load code with
xstream's java xml serialization code.  I'm wondering how people feel
about it.

The advantage is the code is 100% simpler.  5 lines of code replace the
hundreds currently living in SaveService.

The disadvantage is that, without customization, the xstream version of
the files are 3-4x larger.  Speed, however, appears unchanged.

On my local system, JMeter can load both previous versions and xstream
versions, so that's not an issue.  Also, I would include file versioning
with it so that a test plan file would include the jmeter version that
made it.  This would help in the future with backwards compatibility.

I personally like it, but then, a file going from 100k to 400k is no big
deal to me - I don't save 10000 objects in my test plans (100 and 400
are the relative sizes of the guitest.jmx file)

Any opinions?

-- 
Michael Stover <ms...@apache.org>
Apache Software Foundation


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org