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
>