wrapper-user

[Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

Hi,

I'm using wrapper to manage startup and shutdown of a custom server.
During performance testing of the server, the profiler reports a lot
of cpu utilization in the wrapper methods.

To reduce the wrapper communication, I've set the following values in
wrapper.conf -

wrapper.ping.timeout=0
wrapper.ping.interval=3600
wrapper.cpu.timeout=3600

I know that its not advisable, but this was done to reduce the cpu
utilization reported by the profiler.

But inspite of this, the profiler reports that
SocketInputStream.read() called by wrapper is taking a lot of cpu
time.  On reviewing the code, I found that there's a loop that reads
byte by byte from the wrapper socket.

I'm looking at implementing an alternative mechanism that will not
cause so much cpu utilization.  Suggestions welcome.

Regards,
Vinod.

Re: [Wrapper-user] Performance issues

[Hubert F. <hub...@ab...>]

Hi,

Hmm, I tried this with YourKit Java Profiler and didn't notice anything
remarkable. I suppose you talk about WrapperActionServer.java. Looking
at the code I saw, that the regarding section you mentioned, is called
with a timeout of 15 seconds. A command to read consists of just one
byte. A cannot see why this thread should generate much CPU utilisation
neither could my profiler.

Regards
hub





>>> "Vinod Panicker" <vi...@gm...> 14.02.2007 07:21 >>>
Hi,

I'm using wrapper to manage startup and shutdown of a custom server.
During performance testing of the server, the profiler reports a lot
of cpu utilization in the wrapper methods.

To reduce the wrapper communication, I've set the following values in
wrapper.conf -

wrapper.ping.timeout=0
wrapper.ping.interval=3600
wrapper.cpu.timeout=3600

I know that its not advisable, but this was done to reduce the cpu
utilization reported by the profiler.

But inspite of this, the profiler reports that
SocketInputStream.read() called by wrapper is taking a lot of cpu
time.  On reviewing the code, I found that there's a loop that reads
byte by byte from the wrapper socket.

I'm looking at implementing an alternative mechanism that will not
cause so much cpu utilization.  Suggestions welcome.

Regards,
Vinod.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Wrapper-user mailing list
Wra...@li... 
https://lists.sourceforge.net/lists/listinfo/wrapper-user

Re: [Wrapper-user] Performance issues

[Leif M. <le...@ta...>]

Vinod,
    The WrapperManager class uses a Java-standard blocking socket to 
read commands
from the Wrapper process across a local socket.  The readByte calls that 
you are talking
about only happen when a command is received and should be quite lite 
weight.  There
are several commands that come across on startup which may be why this 
is standing out
for you.   But once the Wrapper has started, this should be very lite 
weight.
    Try resetting the profiler counters once the Wrapper has started up.

    As you mentioned, those extended timeouts, especially disabling ping 
timeouts
is going to cause you problems.  I would restore them.

    With those settings in place though, there should not be any 
commands going back
and forth once the Wrapper is started.  (Except the hourly pings)  As 
you are still saying
that you are seeing a load on the readByte method, this must be 
including the startup
code.  On startup, one particular command is quite large.  The Wrapper 
sends the
contents of the wrapper.conf file over so it can be stored into a 
Properties object
within the JVM.

    Most read methods actually call readByte behind the scenes.  I do it 
this way to get the
control over the socket that is needed by the Wrapper.  This should not 
be causing any
extra load as seen by the profiler.

    If you have ideas on how to do this differently, my ears are always 
open.  But I have
not felt that was a problem as currently implemented.

Cheers,
Leif

Vinod Panicker wrote:
> Hi,
>
> I'm using wrapper to manage startup and shutdown of a custom server.
> During performance testing of the server, the profiler reports a lot
> of cpu utilization in the wrapper methods.
>
> To reduce the wrapper communication, I've set the following values in
> wrapper.conf -
>
> wrapper.ping.timeout=0
> wrapper.ping.interval=3600
> wrapper.cpu.timeout=3600
>
> I know that its not advisable, but this was done to reduce the cpu
> utilization reported by the profiler.
>
> But inspite of this, the profiler reports that
> SocketInputStream.read() called by wrapper is taking a lot of cpu
> time.  On reviewing the code, I found that there's a loop that reads
> byte by byte from the wrapper socket.
>
> I'm looking at implementing an alternative mechanism that will not
> cause so much cpu utilization.  Suggestions welcome.
>
> Regards,
> Vinod.
>   

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

Hi,

I'm attaching a zip file that has the call tree and the time taken for
the wrapper method.  I'm capturing the output using Yourkit Profiler.

This is a CPU tracing taken after the system has been running for a
while (not right from startup) as the users are being increased
gradually.  If you see the whole call tree, wrapper is taking up 23%
of the total cpu time.

When the options were left to the default values, this figure was much higher.

Regards,
Vinod.

On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> Vinod,
>     The WrapperManager class uses a Java-standard blocking socket to
> read commands
> from the Wrapper process across a local socket.  The readByte calls that
> you are talking
> about only happen when a command is received and should be quite lite
> weight.  There
> are several commands that come across on startup which may be why this
> is standing out
> for you.   But once the Wrapper has started, this should be very lite
> weight.
>     Try resetting the profiler counters once the Wrapper has started up.
>
>     As you mentioned, those extended timeouts, especially disabling ping
> timeouts
> is going to cause you problems.  I would restore them.
>
>     With those settings in place though, there should not be any
> commands going back
> and forth once the Wrapper is started.  (Except the hourly pings)  As
> you are still saying
> that you are seeing a load on the readByte method, this must be
> including the startup
> code.  On startup, one particular command is quite large.  The Wrapper
> sends the
> contents of the wrapper.conf file over so it can be stored into a
> Properties object
> within the JVM.
>
>     Most read methods actually call readByte behind the scenes.  I do it
> this way to get the
> control over the socket that is needed by the Wrapper.  This should not
> be causing any
> extra load as seen by the profiler.
>
>     If you have ideas on how to do this differently, my ears are always
> open.  But I have
> not felt that was a problem as currently implemented.
>
> Cheers,
> Leif
>
> Vinod Panicker wrote:
> > Hi,
> >
> > I'm using wrapper to manage startup and shutdown of a custom server.
> > During performance testing of the server, the profiler reports a lot
> > of cpu utilization in the wrapper methods.
> >
> > To reduce the wrapper communication, I've set the following values in
> > wrapper.conf -
> >
> > wrapper.ping.timeout=0
> > wrapper.ping.interval=3600
> > wrapper.cpu.timeout=3600
> >
> > I know that its not advisable, but this was done to reduce the cpu
> > utilization reported by the profiler.
> >
> > But inspite of this, the profiler reports that
> > SocketInputStream.read() called by wrapper is taking a lot of cpu
> > time.  On reviewing the code, I found that there's a loop that reads
> > byte by byte from the wrapper socket.
> >
> > I'm looking at implementing an alternative mechanism that will not
> > cause so much cpu utilization.  Suggestions welcome.
> >
> > Regards,
> > Vinod.
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

Naming the file with a .bin ext.  Pls rename it to .zip to open.

On 2/15/07, Vinod Panicker <vi...@gm...> wrote:
> Hi,
>
> I'm attaching a zip file that has the call tree and the time taken for
> the wrapper method.  I'm capturing the output using Yourkit Profiler.
>
> This is a CPU tracing taken after the system has been running for a
> while (not right from startup) as the users are being increased
> gradually.  If you see the whole call tree, wrapper is taking up 23%
> of the total cpu time.
>
> When the options were left to the default values, this figure was much higher.
>
> Regards,
> Vinod.
>
> On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> > Vinod,
> >     The WrapperManager class uses a Java-standard blocking socket to
> > read commands
> > from the Wrapper process across a local socket.  The readByte calls that
> > you are talking
> > about only happen when a command is received and should be quite lite
> > weight.  There
> > are several commands that come across on startup which may be why this
> > is standing out
> > for you.   But once the Wrapper has started, this should be very lite
> > weight.
> >     Try resetting the profiler counters once the Wrapper has started up.
> >
> >     As you mentioned, those extended timeouts, especially disabling ping
> > timeouts
> > is going to cause you problems.  I would restore them.
> >
> >     With those settings in place though, there should not be any
> > commands going back
> > and forth once the Wrapper is started.  (Except the hourly pings)  As
> > you are still saying
> > that you are seeing a load on the readByte method, this must be
> > including the startup
> > code.  On startup, one particular command is quite large.  The Wrapper
> > sends the
> > contents of the wrapper.conf file over so it can be stored into a
> > Properties object
> > within the JVM.
> >
> >     Most read methods actually call readByte behind the scenes.  I do it
> > this way to get the
> > control over the socket that is needed by the Wrapper.  This should not
> > be causing any
> > extra load as seen by the profiler.
> >
> >     If you have ideas on how to do this differently, my ears are always
> > open.  But I have
> > not felt that was a problem as currently implemented.
> >
> > Cheers,
> > Leif
> >
> > Vinod Panicker wrote:
> > > Hi,
> > >
> > > I'm using wrapper to manage startup and shutdown of a custom server.
> > > During performance testing of the server, the profiler reports a lot
> > > of cpu utilization in the wrapper methods.
> > >
> > > To reduce the wrapper communication, I've set the following values in
> > > wrapper.conf -
> > >
> > > wrapper.ping.timeout=0
> > > wrapper.ping.interval=3600
> > > wrapper.cpu.timeout=3600
> > >
> > > I know that its not advisable, but this was done to reduce the cpu
> > > utilization reported by the profiler.
> > >
> > > But inspite of this, the profiler reports that
> > > SocketInputStream.read() called by wrapper is taking a lot of cpu
> > > time.  On reviewing the code, I found that there's a loop that reads
> > > byte by byte from the wrapper socket.
> > >
> > > I'm looking at implementing an alternative mechanism that will not
> > > cause so much cpu utilization.  Suggestions welcome.
> > >
> > > Regards,
> > > Vinod.
> > >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Wrapper-user mailing list
> > Wra...@li...
> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
>

Re: [Wrapper-user] Performance issues

[Leif M. <le...@ta...>]

Vinod,
>From your profile output, it shows that of the CPU time that your
application consumed, 23% was being consumed by the Wrapper reading
from the socket you mentioned, and the remaining 77% was being
consumed by the ThreadPoolExecutor. I assume this is where your
application is running.

This represents the Wrapper consuming a total of 48.5s of CPU time.
For reference, how much actual time was the JVM running for? While
this may look bad, it may simply be a matter of the JVM as a whole being
quite idle.

I have profiled other applications in the past and while the Wrapper
registers on the list, it is always near the bottom as far as CPU usage.

Reviewing the code, I also do not see any reason why this should be
consuming very much code.

If the the 48.5s CPU time is building up over a show actual time frame
then it means that that loop is thrashing somehow. If so, this would be
made obvious by enabling debug output by setting the following property
in the configuration file:

wrapper.debug=true

Cheers,
Leif

Vinod Panicker wrote:
> Naming the file with a .bin ext. Pls rename it to .zip to open.
>
> On 2/15/07, Vinod Panicker <vi...@gm...> wrote:
>> Hi,
>>
>> I'm attaching a zip file that has the call tree and the time taken for
>> the wrapper method. I'm capturing the output using Yourkit Profiler.
>>
>> This is a CPU tracing taken after the system has been running for a
>> while (not right from startup) as the users are being increased
>> gradually. If you see the whole call tree, wrapper is taking up 23%
>> of the total cpu time.
>>
>> When the options were left to the default values, this figure was
>> much higher.
>>
>> Regards,
>> Vinod.
>>
>> On 2/15/07, Leif Mortenson <le...@ta...> wrote:
>> > Vinod,
>> > The WrapperManager class uses a Java-standard blocking socket to
>> > read commands
>> > from the Wrapper process across a local socket. The readByte calls
>> that
>> > you are talking
>> > about only happen when a command is received and should be quite lite
>> > weight. There
>> > are several commands that come across on startup which may be why this
>> > is standing out
>> > for you. But once the Wrapper has started, this should be very lite
>> > weight.
>> > Try resetting the profiler counters once the Wrapper has started up.
>> >
>> > As you mentioned, those extended timeouts, especially disabling ping
>> > timeouts
>> > is going to cause you problems. I would restore them.
>> >
>> > With those settings in place though, there should not be any
>> > commands going back
>> > and forth once the Wrapper is started. (Except the hourly pings) As
>> > you are still saying
>> > that you are seeing a load on the readByte method, this must be
>> > including the startup
>> > code. On startup, one particular command is quite large. The Wrapper
>> > sends the
>> > contents of the wrapper.conf file over so it can be stored into a
>> > Properties object
>> > within the JVM.
>> >
>> > Most read methods actually call readByte behind the scenes. I do it
>> > this way to get the
>> > control over the socket that is needed by the Wrapper. This should not
>> > be causing any
>> > extra load as seen by the profiler.
>> >
>> > If you have ideas on how to do this differently, my ears are always
>> > open. But I have
>> > not felt that was a problem as currently implemented.
>> >
>> > Cheers,
>> > Leif
>> >
>> > Vinod Panicker wrote:
>> > > Hi,
>> > >
>> > > I'm using wrapper to manage startup and shutdown of a custom server.
>> > > During performance testing of the server, the profiler reports a lot
>> > > of cpu utilization in the wrapper methods.
>> > >
>> > > To reduce the wrapper communication, I've set the following
>> values in
>> > > wrapper.conf -
>> > >
>> > > wrapper.ping.timeout=0
>> > > wrapper.ping.interval=3600
>> > > wrapper.cpu.timeout=3600
>> > >
>> > > I know that its not advisable, but this was done to reduce the cpu
>> > > utilization reported by the profiler.
>> > >
>> > > But inspite of this, the profiler reports that
>> > > SocketInputStream.read() called by wrapper is taking a lot of cpu
>> > > time. On reviewing the code, I found that there's a loop that reads
>> > > byte by byte from the wrapper socket.
>> > >
>> > > I'm looking at implementing an alternative mechanism that will not
>> > > cause so much cpu utilization. Suggestions welcome.
>> > >
>> > > Regards,
>> > > Vinod.
>> > >
>> >
>> >
>> >
>> -------------------------------------------------------------------------
>>
>> > Take Surveys. Earn Cash. Influence the Future of IT
>> > Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> > opinions on IT & business topics through brief surveys-and earn cash
>> >
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>> > _______________________________________________
>> > Wrapper-user mailing list
>> > Wra...@li...
>> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
>> >
>>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>   

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> Vinod,
> >From your profile output, it shows that of the CPU time that your
> application consumed, 23% was being consumed by the Wrapper reading
> from the socket you mentioned, and the remaining 77% was being
> consumed by the ThreadPoolExecutor. I assume this is where your
> application is running.

Thats right.

> This represents the Wrapper consuming a total of 48.5s of CPU time.
> For reference, how much actual time was the JVM running for? While
> this may look bad, it may simply be a matter of the JVM as a whole being
> quite idle.

In the telemetry, Yourkit is showing that the JVM ran for 3 minutes.

> I have profiled other applications in the past and while the Wrapper
> registers on the list, it is always near the bottom as far as CPU usage.
>
> Reviewing the code, I also do not see any reason why this should be
> consuming very much code.
>
> If the the 48.5s CPU time is building up over a show actual time frame
> then it means that that loop is thrashing somehow. If so, this would be
> made obvious by enabling debug output by setting the following property
> in the configuration file:
>
> wrapper.debug=true

This should do the trick.  Let me try it out and let you know.

Regards,
Vinod.

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

OK, I ran the application with cpu sampling and tracing and with debug enabled.

According to the code, if there is communication, there should be a
log message in wrapper.log.  There's nothing of that sort, which means
that handleSocket() is not getting invoked.

During sampling, the profiler is reporting cpu usage in the
handleSocket() method call.  During tracing, it shows that the method
has been invoked just once.

Does this make sense to anyone?  Does it look like an issue with the profiler?

Regards,
Vinod.

On 2/15/07, Vinod Panicker <vi...@gm...> wrote:
> On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> > Vinod,
> > >From your profile output, it shows that of the CPU time that your
> > application consumed, 23% was being consumed by the Wrapper reading
> > from the socket you mentioned, and the remaining 77% was being
> > consumed by the ThreadPoolExecutor. I assume this is where your
> > application is running.
>
> Thats right.
>
> > This represents the Wrapper consuming a total of 48.5s of CPU time.
> > For reference, how much actual time was the JVM running for? While
> > this may look bad, it may simply be a matter of the JVM as a whole being
> > quite idle.
>
> In the telemetry, Yourkit is showing that the JVM ran for 3 minutes.
>
> > I have profiled other applications in the past and while the Wrapper
> > registers on the list, it is always near the bottom as far as CPU usage.
> >
> > Reviewing the code, I also do not see any reason why this should be
> > consuming very much code.
> >
> > If the the 48.5s CPU time is building up over a show actual time frame
> > then it means that that loop is thrashing somehow. If so, this would be
> > made obvious by enabling debug output by setting the following property
> > in the configuration file:
> >
> > wrapper.debug=true
>
> This should do the trick.  Let me try it out and let you know.
>
> Regards,
> Vinod.
>

Re: [Wrapper-user] Performance issues

[Leif M. <le...@ta...>]

Vinod,
    That is actually correct.  The handleSocket method gets called once 
when the
socket is opened.  It is called with a dedicated thread called 
"Wrapper-Connection".
The handleSocket method then loops until the socket is closed or the JVM 
shuts
down.  In that loop, the DataInputStream.readByte() method will be 
called at least
once for each command received from the Wrapper process.
    If any commands are send, they will show up in the log file with 
wrapper.debug
enabled.

    I wonder if the profiler is getting confused by the native call 
inside the read
method.  That method is blocking on the socket at a low level.  I'm not 
sure how
often the OS is spending actual CPU cycles in that call.  It should be 
pretty much
idle unless any data is coming in however.

    Are you able to see a call count on the DataInputStream.readByte 
method as it
is called from within the handleSocket method?

Cheers,
Leif

Vinod Panicker wrote:
> OK, I ran the application with cpu sampling and tracing and with debug enabled.
>
> According to the code, if there is communication, there should be a
> log message in wrapper.log.  There's nothing of that sort, which means
> that handleSocket() is not getting invoked.
>
> During sampling, the profiler is reporting cpu usage in the
> handleSocket() method call.  During tracing, it shows that the method
> has been invoked just once.
>
> Does this make sense to anyone?  Does it look like an issue with the profiler?
>
> Regards,
> Vinod.
>   

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

Hi,

There are no calls reported to DataInputStream.readByte() when CPU
tracing is enabled.  That makes sense, since the wrapper ping interval
is kept to the max amount and the profling snapshot is being taken
after the application has been running for a while.

I'll revert back to the old default values for the wrapper settings
and will use the current values only for profling.  I'll also get in
touch with the Yourkit guys and get some more info on this behaviour.

Thanks for the help.

Regards,
Vinod.

On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> Vinod,
>     That is actually correct.  The handleSocket method gets called once
> when the
> socket is opened.  It is called with a dedicated thread called
> "Wrapper-Connection".
> The handleSocket method then loops until the socket is closed or the JVM
> shuts
> down.  In that loop, the DataInputStream.readByte() method will be
> called at least
> once for each command received from the Wrapper process.
>     If any commands are send, they will show up in the log file with
> wrapper.debug
> enabled.
>
>     I wonder if the profiler is getting confused by the native call
> inside the read
> method.  That method is blocking on the socket at a low level.  I'm not
> sure how
> often the OS is spending actual CPU cycles in that call.  It should be
> pretty much
> idle unless any data is coming in however.
>
>     Are you able to see a call count on the DataInputStream.readByte
> method as it
> is called from within the handleSocket method?
>
> Cheers,
> Leif
>
> Vinod Panicker wrote:
> > OK, I ran the application with cpu sampling and tracing and with debug enabled.
> >
> > According to the code, if there is communication, there should be a
> > log message in wrapper.log.  There's nothing of that sort, which means
> > that handleSocket() is not getting invoked.
> >
> > During sampling, the profiler is reporting cpu usage in the
> > handleSocket() method call.  During tracing, it shows that the method
> > has been invoked just once.
> >
> > Does this make sense to anyone?  Does it look like an issue with the profiler?
> >
> > Regards,
> > Vinod.
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Wrapper-user mailing list
> Wra...@li...
> https://lists.sourceforge.net/lists/listinfo/wrapper-user
>

Re: [Wrapper-user] Performance issues

[Vinod P. <vi...@gm...>]

A final update on this issue.  I got this reply on the Yourkit forums -

"If a native method performs waiting directly using OS calls, Java
obviously cannot know what exactly the method does, and will report it
as running. If OS cannot provide actual thread CPU time, the time when
that native method runs and when it waits cannot be separated."

So rather than this being an issue with wrapper, its actually a
limitation of the platform.

Regards,
Vinod.

On 2/16/07, Vinod Panicker <vi...@gm...> wrote:
> Hi,
>
> There are no calls reported to DataInputStream.readByte() when CPU
> tracing is enabled.  That makes sense, since the wrapper ping interval
> is kept to the max amount and the profling snapshot is being taken
> after the application has been running for a while.
>
> I'll revert back to the old default values for the wrapper settings
> and will use the current values only for profling.  I'll also get in
> touch with the Yourkit guys and get some more info on this behaviour.
>
> Thanks for the help.
>
> Regards,
> Vinod.
>
> On 2/15/07, Leif Mortenson <le...@ta...> wrote:
> > Vinod,
> >     That is actually correct.  The handleSocket method gets called once
> > when the
> > socket is opened.  It is called with a dedicated thread called
> > "Wrapper-Connection".
> > The handleSocket method then loops until the socket is closed or the JVM
> > shuts
> > down.  In that loop, the DataInputStream.readByte() method will be
> > called at least
> > once for each command received from the Wrapper process.
> >     If any commands are send, they will show up in the log file with
> > wrapper.debug
> > enabled.
> >
> >     I wonder if the profiler is getting confused by the native call
> > inside the read
> > method.  That method is blocking on the socket at a low level.  I'm not
> > sure how
> > often the OS is spending actual CPU cycles in that call.  It should be
> > pretty much
> > idle unless any data is coming in however.
> >
> >     Are you able to see a call count on the DataInputStream.readByte
> > method as it
> > is called from within the handleSocket method?
> >
> > Cheers,
> > Leif
> >
> > Vinod Panicker wrote:
> > > OK, I ran the application with cpu sampling and tracing and with debug enabled.
> > >
> > > According to the code, if there is communication, there should be a
> > > log message in wrapper.log.  There's nothing of that sort, which means
> > > that handleSocket() is not getting invoked.
> > >
> > > During sampling, the profiler is reporting cpu usage in the
> > > handleSocket() method call.  During tracing, it shows that the method
> > > has been invoked just once.
> > >
> > > Does this make sense to anyone?  Does it look like an issue with the profiler?
> > >
> > > Regards,
> > > Vinod.
> > >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Wrapper-user mailing list
> > Wra...@li...
> > https://lists.sourceforge.net/lists/listinfo/wrapper-user
> >
>

Re: [Wrapper-user] Performance issues

[Leif M. <le...@ta...>]

Vinod,
Great.  Thanks for the update on this. :-)

Cheers,
Leif

Vinod Panicker wrote:
> A final update on this issue.  I got this reply on the Yourkit forums -
>
> "If a native method performs waiting directly using OS calls, Java
> obviously cannot know what exactly the method does, and will report it
> as running. If OS cannot provide actual thread CPU time, the time when
> that native method runs and when it waits cannot be separated."
>
> So rather than this being an issue with wrapper, its actually a
> limitation of the platform.
>
> Regards,
> Vinod.
>