Clay Webster wrote:
Hey Ian, these version with all the parameter options only shows the
table headers.. no data. (No requests?)
it's a bug with the collector
try http://pyro.holsman.net:9081/top/?hours=72
and I'll work on getting more load pushed through it. (It comes with a
log replay tool as well)
PS: I think there's interest. ;-)
--cw
On 6/19/07, Ian Holsman <[EMAIL PROTECTED]> wrote:
I've been working on a tool to parse log files to get some of this kind
of information as well
it's really alpha, but if your curious the dummy system is here:
http://pyro.holsman.net:9081/top/ -- slightly obfuscated queries (to
roll them up)
http://pyro.holsman.net:9081/overall/?period=5m&hours=12 -- # of
requests, response time, and deviation in that
http://pyro.holsman.net:9081/overall/?period=5m&hours=12&format=csv&cols=1,2,5,6,7,8
- same thing as a CSV file and showing selected columns
The aim is to use this as a data source for something like cacti and
sticking a flash graph on top of it.
If there is enough interest I can contribute this to solr
Yonik Seeley wrote:
> requestsPerSecond and averageResponseTime were added to statistics for
> each response handler. Are these statistics really useful enough to
> keep as-is?
>
> averageResponseTime is cumulative since the server started, so it's
> not useful for monitoring purposes, but only benchmarking purposes (it
> won't tell you if your queries are getting slower all of a sudden).
> (it will also count slower warming queries, not just live queries).
>
> requestsPerSecond is likewise flawed... it won't let you detect a
> flood of traffic or a dropoff. Also, if you turned off traffic to the
> server yesterday, that will continue to be reflected in the
> requestsPerSecond today.
>
> Since it seems like these parameters are only useful for benchmarking
> (which can easily be done from log files), perhaps we should defer
> adding them until we can come up with versions that are useful for
> monitoring?
>
> -Yonik
>
