Friday, February 18, 2011

We have just released RHQ 4.0 Developer Preview 3. This release is intended for developers and other interested parties who want a first-hand look at upcoming changes in RHQ 4.0, in particular the new GWT UI. Please note that this release is not intended for production use or serious testing.

New Features:* Improved dashboard* Improved operations UI (for single resource)* Improved bundles UI* System settings have been ported to GWT* Support for Postgres 9.0* Support for deleting agent plugins

Friday, February 04, 2011

Dynamic: metric values are 'randomly' going up and down. An example could be the free main memory of a computer

Trendsup: a metric whose values are monotonically increasing. This could e.g. be the number of transactions committed or request served

Trendsdown: the counterpart of trendsup where values are monotonically decreasing.

Usually the absolute number of commits or requests does not really tell much. More interesting is the dirst deviation by time: how many requests are coming in per minute. Here you can directly see if you have a request storm coming in or if it is quiet.

Now lets have a look at an excerpt from a screen shot of the metrics table in RHQ:

Screenshot from RHQ UI (non-interesting lines cut out)

Here we see that the minimum number of requests served in the last 1day was 327.100 and the maximum number was 333.540. This sounds strange at first glance. Actually this does not mean within the last 24h we served somewhere between 327k and 333k requests, but rather that at the start of the last 24h period, the counter was at 327k and at then end it was at 333k. The following diagram illustrates this:

The position in time of the green bar is "now".

And now we can do the math:

333540 - 327100 = 6440 requests in the last 24h

6440 / ( 26 * 60 ) = 4.47 requests per minute (on average)

And those 4.47 requests are the 4.6 you see as avg. requests per minute in above graph (modulo some rounding issues).

The counter for "requests served" will be reset to zero when the web-app is started again e.g. by fully restarting the web-container (or app server) .