geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Statistics Management and Jetty/Tomcat
Date Wed, 07 Dec 2005 19:39:31 GMT
Greg,

Sorry for the delay in getting back to you on this.  I did try out 
Jetty5.1.7rc0 and have the following results.

However, before I tell you the results I need to mention that it doesn't 
appear that this Geronimo function is going to make Geronimo V1. I don't 
think anybody else needs a new Jetty image and I don't think this 
function is critical enough to force the issue before we cut the 
Geronimo V1 image.

Things went fairly well with the new image.  There were no major 
problems.  Here's what I noticed:

There were some missing APIs that didn't make it from my list to your 
list in a later append:
- getConnectionsRequestsCurrent()
- getRequestsDurationCount()
- getConnectionsDurationCount()

There were some other strange things I observed as well:
- A number of fields are never set greater than zero
   - errors (hopefully because there were no errors)
   - RequestsActiveMin (I guess it's fair to say zero is the low)
   - ConnectionsOpenMin (ditto)
   - RequestsDurationMin - this was strange because I would see this get 
set sometimes for a few seconds and then get reset to zero.

I also notices that when I initially began collecting the Stats it took 
some time before I would get the initial values (kept returning zero's). 
  It seemed that the more impatient I was (hitting refresh often) ... 
the longer it took to get any valid data back.

I also noticed that the number for some things (like the total requests) 
grew at an unreasonable rate initially (like with each request I made to 
the server the total would jump by 20-25.  However, after a bit longer 
the number became more accurate and each refresh I did resulted in just 
one additional request in the total.

Thanks again for working on this.  Even though it doesn't look like 
we'll exploit these additional values in Geronimo v1 we will certainly 
need them in the near future.

Thanks,
Joe


Greg Wilkins wrote:
> Joe Bohn wrote:
> 
> 
>>That's correct.  In fact, at the moment I'm just trying to get a more
>>generic management implementation of the container stats in the style of
>>the JSR77 stats ... but I'm not really looking for the JSR77 servlet
>>stats right now.   You mentioned in another note that you were hoping to
>>create a new jetty image soon.
> 
> 
> Yep - I'd like to get a 5.1.7 out by mid week before apachecon.
> So I'll add these methods today and make a snapshot. If you can test ASAP
> that will help with the timing.
> 
> 
>>I think our needs to complete what we are already receiving in part from
>>Jetty would be met if you could provide these container statistics:
>>- getConnectionsOpenMin
>>- getConnectionsRequestsMin
>>- getConnectionsRequestsCurrent
>>- getConnectionsDurationMin
>>- getConnectionsDurationCount
>>- getConnectionsDurationTotal
>>- getRequestsActiveMin
>>- getRequestsDurationMin
>>- getRequestsDurationCount
>>- getRequestsDurationTotal
> 
> 
> I'm not sure all these make sense?   ConnectionsRequests is
> a stat about the number of requests per connection (OK badly named),
> as such there is no current value.  Also the getRequestsActiveMin is going
> to be zero - unless you have a stats reset method that can be called on a busy
> server.
> 
> Also some of the Counts and Totals are already provided (eg RequestDurationCount
> is just the number of requests).
> 
> 
> So would you be OK with the following stats:
>     
>     private transient long _statsStartedAt=0;            // time stats collection started
>     
>     private transient int _connections;                  // total number of connections
made to server
>     
>     private transient int _connectionsOpen;              // number of connections currently
open
>     private transient int _connectionsOpenMin;           // min number of connections
open simultaneously
>     private transient int _connectionsOpenMax;           // max number of connections
open simultaneously
>     
>     private transient long _connectionsDurationMin;      // min duration of a connection
>     private transient long _connectionsDurationMax;      // max duration of a connection
>     private transient long _connectionsDurationTotal;    // total duration of all coneection
>     
> 
>     private transient int _errors;                       // total bad requests to the
server
>     private transient int _requests;                     // total requests made to the
server
> 
>     private transient int _requestsActive;               // number of requests currently
being handled
>     private transient int _requestsActiveMin;            // min number of connections
handled simultaneously
>     private transient int _requestsActiveMax;            // max number of connections
handled simultaneously
>     
>     private transient int _connectionsRequestsMin;       // min requests per connection
>     private transient int _connectionsRequestsMax;       // max requests per connection
> 
>     private transient long _requestsDurationMin;         // min request duration
>     private transient long _requestsDurationMax;         // max request duration
>     private transient long _requestsDurationTotal;       // total request duration
>     
>     
> I'm assuming yes and have started updating Jetty    
> 
> 
> 
>>There is one other matter regarding how stats are enabled/disabled.  I
>>don't see in the JSR77 spec where this type of processing is available.
>> It looks like stats are always presumed to be active.  However, since
>>the jetty stats can be enabled and disabled at any time I've been
>>thinking of extending the JSR77-like container stats to also include the
>>notion of enabling and disabling the collect of statistics in the
>>WebContainerStats interface.  Are there thoughts from those that are
>>better versed in JSR77 about the ability to enable/disable the
>>collection of stats?
> 
> 
> It is important to be able to disable stats collection.  Stats are expensive as
> they represent an extra sync lock that all requests must grab several times 
> during processing (oh for a atomic ++ in java 1.4)
> 
> If you want the min values, then a reset is also worth while.
> 
> 
> cheers
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
Joe Bohn
joe.bohn@earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Mime
View raw message