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.
>