Cms: Add GeneralConfig item to limit `queue/get-job-info` (improve queue performance in the CP)

[dsmrt]

Description

We utilize the queue heavily. On one site I loaded 200k+ jobs which severely impacted the control panel to the point where it was taking 30-60 seconds to load a page in the backend. For environment background and configuration:

On this install, we have separate worker containers for the queue (separate from the web app containers, so they are isolated) and runQueueAutomatically turned off.
(Ref: https://github.com/craftcms/cms/pull/4419#issuecomment-510583760 )

As suggested by @gtettelaar (https://github.com/craftcms/cms/pull/4419#issuecomment-510596526), it would be nice to be able manage query limits for queue/get-job-info. Possibly even set it to zero, because we really don't use that.

Steps to reproduce

1. Load 20k+ jobs into the queue
2. Load a page in the control panel

Additional info

• Craft version: 3.1, 3.2
• PHP version: php 7.2
• Database driver & version: mysql 5.7
• Plugins & versions: n/a

[ghost]

+1, the amount of jobs shown in the CP should be limited. My browser window froze for more than 10 minutes after which it finally crashed because of the queue info. There were 12.000+ jobs so I'm guessing the huge amount of html elements inside the modal were the culprit.

The queue also causes the CP to become really slow when executing specific jobs or a lot of them. I rather have a slow queue than a slow CP. At some point I started getting a 504 gateway timeout error, so I was unable to use the site for around 15 minutes. It could be coincidence but I don't think it was.

[markhuot]

This is affecting me as well. I'm working on an import of 1M+ rows from an existing CMS in to Craft. During the import I end up with 1M+ "Updating search indexes" which just slows everything down to a crawl. I have the actual Queue running via a console command so I'd be happy to just disable the CP UI entirely, if that's the easiest solution.

[nateiler]

Disabling properly via config is preferred, but until a first party solution is provided:

        if (Craft::$app->getRequest()->getIsCpRequest()) {
            Craft::$app->getView()->registerJs('Craft.cp.enableQueue = false;');
        }

One call to get queue items is called, but no more DDoS.

[markhuot]

I went a step further to remove the code all together from the CP. It's _extremely_ gross but also prevents that one queue query.

Craft::$app->view->hook('cp.layouts.base', function (array $context) {
    if (!isset($context['view']->js)) {
        return;
    }

    if (!is_array($context['view']->js)) {
        return;
    }

    foreach ($context['view']->js as $priority => &$codes) {
        foreach ($codes as &$code) {
            if (strpos($code, 'Craft.cp.setJobInfo') === 0) {
                $code = 'Craft.cp.enableQueue = false;';
            }
        }
    }
});

[brandonkelly]

We just made some big queue changes for Craft 3.4 – first, no more than 50 jobs will ever be loaded by that Ajax request, so it won’t bog down the control panel no matter how many thousands of jobs are queued up. We’ve also added a new Queue Manager utility (#2753) and a queue/release all command (#4777).