We could only have average "concurrency" in each carbon cycle, but in_request changes all the time so keep in mind that it will be average of few samples, so it will further reduce it's accuracy. It should be easy so if this is useful I can add such metric. How should I name it?
2013/2/5 Roberto De Ioris <[email protected]> > > > 2013/2/5 André Cruz <[email protected]> > > > >> > >> > >> > Yous should have per worker metrics, There is --carbon-no-workers > >> switch > >> but AFAIR it is disabled by default. > >> > >> I do have per-worker metrics, I just can't find one that tells me how > >> many > >> concurrent requests are being served at a given time. Did I miss it? I > >> only > >> found one metric named "requests" but this seems just a running counter. > > > > > > Sorry I don't recall such metric, only the total number of requests > served > > by given worker. You can get rate out of that, but not concurrency. > > > > > > I suppose the "concurrency" could be the sum of all of the > workers->cores->X->in_request fields with a value of 1. > > Showing it in uwsgitop would be pretty easy, but i suppose a whole new > metric will be required for carbon. > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
