axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: AXIS-1423 : Peter's test case for performance
Date Fri, 16 Jul 2004 22:20:06 GMT
Also since the client takes too long to deserialize the stuff, it
might be faster to use JMeter to test the server-side
(http://www-106.ibm.com/developerworks/opensource/library/os-jmeter/)

-- dims

On Fri, 16 Jul 2004 13:28:01 -0700, Peter Molettiere
<pietro@axonstudios.net> wrote:
> 
> The problem isn't OOM -- it's a leak. Watch it in a profiler. I'll get
> the latest beta and try that too. Per Tom Jordahl's suggestion, I'm
> trying to pin it down myself -- it was a coworker who actually created
> the test case, so I'm in the process of installing a profiler and
> getting everything setup to run there.
> 
> I'll post more later as I find it.
> 
> --Peter
> 
> 
> 
> On Jul 16, 2004, at 1:08 PM, Davanum Srinivas wrote:
> 
> > any other tips? still not able to get OOM. Can you please try with
> > latest CVS? (don't use streaming on the server-side use the regular
> > deploy.wsdd, just do it on the client side via the command line switch
> > that you have).
> >
> > thanks,
> > -- dims
> >
> > On Fri, 16 Jul 2004 12:39:38 -0700, Peter Molettiere
> > <pietro@axonstudios.net> wrote:
> >>
> >> Try running a larger heap size on the client so you don't get the OOM
> >> on the client. Then you'll be able to see the leak on the server.
> >>
> >> --Peter
> >>
> >>
> >>
> >> On Jul 16, 2004, at 12:22 PM, Davanum Srinivas wrote:
> >>
> >>> Peter,
> >>>
> >>> So far i have not been able to recreate the leak on the server-side
> >>> with latest CVS. I have been getting OutOfMemory on the client
> >>> though...and am working to clean up some stuff for that.
> >>>
> >>> -- dims
> >>>
> >>> On Fri, 16 Jul 2004 11:26:36 -0700, Peter Molettiere
> >>> <pietro@axonstudios.net> wrote:
> >>>>
> >>>> Hey guys,
> >>>>
> >>>> We set the numbers high to make the problem manifest easily,
> >>>> however,
> >>>> if you set the return message size smaller, you'll still see the
> >>>> server
> >>>> side memory leak, it will just take much longer to notice, since you
> >>>> have to leak much more memory before the
> >>>> serialization/deserialization
> >>>> overhead (which is itself much smaller due to the smaller message
> >>>> size)
> >>>> bumps into the max heap size limit.
> >>>>
> >>>> We're mainly concerned with the server leaking memory, rather than
> >>>> the
> >>>> large amount of memory used during serialization/deserialization,
> >>>> since
> >>>> it eventually crashes our server, whereas we can just install more
> >>>> RAM
> >>>> and increase our heap size to get around the gobs of memory used
> >>>> during
> >>>> serialization.
> >>>>
> >>>> --Peter
> >>>>
> >>>>
> >>>>
> >>>> On Jul 16, 2004, at 9:26 AM, Davanum Srinivas wrote:
> >>>>
> >>>>> Glen,
> >>>>>
> >>>>> Uploaded a slightly revved version of Peter's test case. Note that
> >>>>> there are 15 threads each issuing 50 calls against a service that
> >>>>> delivers a 13 MB XML  (Please edit the client code to restore the
> >>>>> original params if needed)
> >>>>>
> >>>>> http://nagoya.apache.org/jira/browse/AXIS-1423
> >>>>>
> >>>>> -- dims
> >>>>>
> >>>>> --
> >>>>> Davanum Srinivas - http://webservices.apache.org/~dims/
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Davanum Srinivas - http://webservices.apache.org/~dims/
> >>
> >>
> >
> >
> > --
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message