You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Davanum Srinivas <da...@gmail.com> on 2004/07/16 18:26:38 UTC
AXIS-1423 : Peter's test case for performance
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/
Re: AXIS-1423 : server side memory leak
Posted by Peter Molettiere <pi...@axonstudios.net>.
OK, finally got some time to spend with the profiler, and this is what
I'm seeing. But first, maybe a little explanation of what I did to run
the test.
Tomcat 4.1.30 -- although not the latest axis cvs snapshot, just a
modified beta 1 at this point. (We've modified it to do gzip
compression and keep alive using HttpClient).
I ran the test client with -Xmx1024M to prevent the client from hitting
out of memory errors. The server is being profiled with JProfiler
(demo).
Re: AXIS-1423 : Peter's test case for performance
Posted by Davanum Srinivas <da...@gmail.com>.
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
<pi...@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
> > <pi...@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
> >>> <pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Davanum Srinivas <da...@gmail.com>.
Thanks Peter. It would be better to pull down the current cvs and
compile it yourself...
-- dims
On Fri, 16 Jul 2004 13:28:01 -0700, Peter Molettiere
<pi...@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
> > <pi...@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
> >>> <pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Peter Molettiere <pi...@axonstudios.net>.
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
> <pi...@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
>>> <pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Davanum Srinivas <da...@gmail.com>.
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
<pi...@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
> > <pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Peter Molettiere <pi...@axonstudios.net>.
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
> <pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Davanum Srinivas <da...@gmail.com>.
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
<pi...@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/
Re: AXIS-1423 : Peter's test case for performance
Posted by Peter Molettiere <pi...@axonstudios.net>.
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/