Overheads

[oliver...@googlemail.com]

Hello,
What is are the overheads of adding JavaMelody to a server, i.e. how
much memory and CPU does the application use?
Regards
Oliver

[evernat]

Architecture of JavaMelody is lightweight. So it has a lower overhead
as I can compare it to other available solutions.
The overhead is so low that it can be enabled continuously in QA
environment. And if no problem arises in QA, also continuously in
production environment : it is made for that. (It is already used in
QA and production with an application of 25 person years.)

Why is the overhead low ?
- First, it does monitoring not profiling : there is no
instrumentation of classes like some well known profilers (NetBeans
profiler for example) or some monitoring tools. JavaMelody has instead
"interceptors" for http, jdbc by default, and spring or ejb3 if you
wish so.
- Second, I would say that the overhead of some other good monitoring
solutions is in the recording of each event in a database or in a
master server. With JavaMelody, there is no database and no recording
of each events even in a file or over the wire like most others : only
statistics of requests are kept, so the overhead of cpu is minimal
with no I/O on the wire and minimal I/O on disk (just to take a backup
of statistics at a regular interval). Likewise, it is only statistics
and not events so the overhead of memory is quite minimal.
- Third, with little overhead you will be able to know what needs
optimizing in the QA or production server(s). So that the overhead of
JavaMelody will be negative.
- Fourth, if overhead does really some pain for your app with
thousands active users, you will have the choice to use javamelody
centralized collect server. It unloads the memory, the backup storage
and the generation of reports to another server while adding I/O on
the wire for sending deltas of the statistics.
- Fifth, the financial overhead is zero as JavaMelody is opensource
and free.

For full disclosure, some system actions (disabled by default) can
consume some cpu. These system actions are : Launch the garbage
collector, Take a heap dump, Display memory histogram.

I do not have figures, but overhead is probably under 5% of cpu and of
memory, except if you are not reasonable at all when enabling
monitoring of spring or ejb3.
Do these explanations convince you ?

Emeric


On 24 nov, 23:55, "oli...@gtwm.co.uk" <oliver.ko...@googlemail.com>
wrote:

[oliver...@googlemail.com]

Thanks, I'll give it a go, you've obviously thought about how to
minimise overheads carefully. Running the collect server on a second
machine is an option for me if necessary.

Oliver Kohll

[dhartford]

My quick review on a jboss env with an EJB application (i.e. show
counters for sql, ejb, http, log, error) did show performance
degradation while it was enabled. I wanted to be careful in my
wording, in that I didn't evaluate CPU/memory overload, but the
performance of the application was impacted with all those counters
enabled. Unfortunately, the numbers varied greatly, and my guess
would be related to the EJB interceptors as some of the 'busier' ejb
methods were the ones that had a much larger performance degradation
than others. Simple sql-ejb-http calls and statistics didn't have
much performance degradation at all, as to why I'm taking a guess at
the EJB interceptor when there is a lot of processing code in place.
Although it would be nice to improve this, I would be careful to keep
the easy-enabled approach in place -- some toolkits give you a lot of
options/controls to optimize those statistic collections, which in
turn make it much more complex to setup and maintain.

disabled=true however did indeed bring performance back to normal, and
comparable to when I didn't have javamelody enabled. That is a big
deal, as it shows there is a clean separation between the application
and the statistic gathering.

This was all tested through a load-test scenario with Jmeter.

[dhartford]

oh, forgot to add, no more or less degradation than compared to other
profile/statistic gathering tools! :-)

-D

[evernat]

For Spring, it is said in the user guide "it is not recommended for
the response time to monitor execution of all methods of Spring beans,
for example the methods of low granularity as getters of entities".
Perhaps I should say the same for EJB3 interceptors.
The chapters are purposely named "business façades" (ejb3 or spring).

Could you please say to us what is the granularity of the ejb3 methods
you monitored. Is it more ejb3 entities or ejb3 session façades or
both ? Or more precisely what are the number of *hits* of ejb3 methods
compared to the number of hits of http requests ?

Thanks
(In any case, this is a confirmation that ejb3 monitoring works in
jboss)

[evernat]

Note that you can list monitored ejb3 with something like this in ejb-
jar.xml :

<ejb-jar
xmlns = "http://java.sun.com/xml/ns/javaee"
version = "3.0"
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
>
<interceptors>
<interceptor>
<interceptor-
class>net.bull.javamelody.MonitoringInterceptor</interceptor-class>
</interceptor>
</interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name>FacadeBean1</ejb-name>
<interceptor-
class>net.bull.javamelody.MonitoringInterceptor</interceptor-class>
</interceptor-binding>
<interceptor-binding>
<ejb-name>FacadeBean2</ejb-name>
<interceptor-
class>net.bull.javamelody.MonitoringInterceptor</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar>

where FacadeBean1 and FacadeBean2 are the name of the ejb3 classes.

[dhartford]

This is confirmation of EJB3 monitoring on Jboss 5.1. I had some
issues with jboss 4.0.5 that were related to logging (see
http://code.google.com/p/javamelody/issues/detail?id=6).

I am using the xml interceptor approach, but I'm actually keeping with
the '*' approach for easy setup/deployment.

Traditionally you can expect many EJB hits per HTTP request (from an
architecture point of view, one HTTP request should make one remote
EJB call, but that remote EJB call could make many local EJB calls
(hopefully not more remote EJB calls, but it can happen)). Note
though, that I have done projects where the HTTP/servlet layer will
make local EJB calls since I control the full stack and optimize it as-
such. The test I did above was with all remote EJB calls, with one
being a SFSB, confirming that as well.

I haven't done a formal review of where some of those concerns are
coming from, only can confirm that some exist but are not hampering
the usage of the tool (anyone who is used to profile/tracing has the
expectation of some performance degradation). The degradation is
nothing like Eclipse TPTP with full profiling options, so shouldn't be
overly concerned until some more details surface.

-D

On Nov 30, 3:54 pm, evernat <ever...@free.fr> wrote:
> Note that you can list monitored ejb3 with something like this in ejb-
> jar.xml :
>
> <ejb-jar
>         xmlns = "http://java.sun.com/xml/ns/javaee"
>         version = "3.0"
>         xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"

>         xsi:schemaLocation = "http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"