Could queuedtracking:monitor command also report number of requests processed per second?

[mattab]

Could queuedtracking:monitor command also report number of requests processed per second?

Currently output looks like this:

Queue is enabled
The command ./console queuedtracking:process has to be executed to process request sets within queue
Up to 16 workers will be used
Processor will start once there are at least 100 request sets in the queue
43970 (2863+2646+2970+2818+2724+2776+2608+2619+2874+2625+2788+2688+2457+2624+3050+2840) request sets left in queue. disabled used memory (disabled peak). 0 workers active.

It would be interesting if it could also say:

1,555 requests were processed in the last second

[tsteur]

The process command does it... it would be hard for the monitor to do it

[mattab]

or maybe it could be something like a running summary of the last 60 seconds (or since the script started if less than 60 seconds):

6918 (369+419+443+434+370+292+436+460+495+472+439+465+467+439+472+446) request sets left in queue. 7 workers active. avg in the last minute: 450 new requests per second, 400 processed requests per second (maybe it would say request set instead of request)

[tsteur]

It would be great if you think of a way this could be implemented technically

[tsteur]

just fyi: eg with redis you always only know how many requests are in the queue... but you don't know how many had been processed in between. Eg just because you always see 100K requests in queue doesn't mean no requests had been processed. Could be zero or could be 10000req/s.

The only one who kind of knows is the processor roughly. It would need couple events/hooks to process this information on the fly and eg write roughly every couple seconds this into a table where the monitor can access it for each processor. And it would need to be smart enough to delete the req/s option entry when finished or failed, or outdated (eg entry older than X seconds)

[mattab]

Thanks for the note! considering how complex it would be, let's skip this for now until we really need more detailed QueuedTracking monitoring.

[tsteur]

I actually wouldn't write any update script and not move queued requests into a different queue after the update. There are not too many things that can happen only in some edge cases where it maybe would create a new visit with fewer actions when two different queues track the pageview at the same time. And most of the time queues might be quite empty anyway so it pretty much shouldn't be an issue at all.

[rvdbreemen]

This feature is actually really something we would love to see on QT. As there is hardly any metrics coming out of QT, and this would help a lot to monitor QT in production.