cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cleaning up the CVS
Date Wed, 12 Dec 2001 14:14:26 GMT
Marcus Crafter wrote:
> 
> Hi Stefano,
> 
>         Well, I should step forward and take some of the heat here.
> 
> Stefano Mazzocchi wrote:
> > 6) the code contains a number of things that I found.... well.... let's
> > me look for a polite way of saying this.... hmmm, ehmmmm, errrr, .....
> >
> >             if (this.getLogger().isDebugEnabled()) {
> >                 incRequestCount();
> >                 if (this.getLogger().isDebugEnabled()) {
> >                     this.debug(environment, null, null);
> >                 }
> >             }
> 
>         I am partially responsible for this. The code below and part of the
>         above came from a patch which I contributed

ok, thanks for stepping up.

> > 7) still looking into Cocoon.java:748
> >
> >     /**
> >      * Increment active request count for incoming requests, and save
> > this
> >      * result if it's the maximum.
> >      */
> >     private static synchronized void incRequestCount() {
> >         if (++activeRequestCount > maxRequestCount) {
> >             maxRequestCount = activeRequestCount;
> >         }
> >     }
> >
> >     /**
> >      * Decrement active request count.
> >      */
> >     private static synchronized void decRequestCount() {
> >         --activeRequestCount;
> >     }
> >
> > what are these for? are you aware of the fact that adding a synchronized
> > methods to the front door might create a *huge* bottleneck on high
> > load!?!?!
> 
>         Yes, I am aware that this adds an extra overhead - the above methods
>         should only be called if the application is logging debug statements.

ok

>         Ironically, I actually added these methods to our version of Cocoon to
>         monitor what was happening while testing Cocoon under load, and also
>         during a day's work in production.

well, it's the quantum observer problem: looking at a system might
destroy the information that it previously contained. I mean:
introducing a potential bottleneck to test load might give you more
problems that it solved.

>         The idea was simply to log accurately, per request, the total number of
>         requests being served at that time, and the maximum number of
>         requests served for the applications life period.

see below
 
>         Being able to gauge such internal cocoon usage using this code has
>         been invaluable for us, and has also helped us to fix 2 dynamic
>         compilation problems in Cocoon (wrt sitemap & xsp code) and a session
>         management problem wrt our application.

cool, I'm happy it was useful, but I question the general usefulness of
such a thing.
 
>         My apologies if the code is not efficient, and I won't defend it
>         if you think it's wrong. 

Well, the above code is clearly redundant and please let's avoid these
things in the future (not only for you, Marcus, I mean for everybody).

>         I'm quite keen to learn of a better way to
>         ascertain this information and I'm open if you have any suggestions
>         about how to improve it ?

The code seems to be collecting the maximum number of incoming
concurrent requests. It might be useful, I don't know, but for sure it
doesn't require synchronization. I mean: adding and subtracting one to a
counter is an atomic operation (on ints, it's not on longs, but we don't
have that many requests anyway).

The non-atomic operation is the comparison with previous maximum. One
possible simple solution is to have a sampling thread that reads that
value and logs it someplace. It might be useful for profiling
information.

What do you think?

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message