SiteStats uses:
self::$jobs = $dbr->estimateRowCount( 'job' );
which simply shows 0 if the job queue doesn't use that table (e.g. for the Redis queue).
Example: https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=statistics shows jobs="0"
Version: 1.22.0
Severity: normal
URL: https://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&siprop=statistics
I don't think so. Let's keep that specifically for relational databases (specifically, it seems to boil down to Rob Church's note, "The job queue count shown on Special:Statistics is generated using a clever
trick which avoids an expensive COUNT(*) on the job table. This trick means
that the value will fluctuate, often to the point where it's downright
incorrect.").
The current Redis job queue implementation is totally different (doesn't use a relational database and takes advantage of Redis-specific features).
Change 71966 had a related patch set uploaded by Aaron Schulz:
jobqueue: improved performance of JobQueueGroup::getQueuesWithJobs()
As a sidenote, remember you can now use https://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=hume.wikimedia.org&v=823574&m=Global_JobQueue_length&r=hour&z=default&jr=&js=&st=1365625056&z=large (it was enough for the use case of the dupe).
Change 71966 merged by jenkins-bot:
jobqueue: improved performance of JobQueueGroup::getQueuesWithJobs()