[DISCUSSION]Skip job groups in _group_result when starting with '~'

[okurz]

As of 2016-02-26 we encountered a major performance regression on
openqa.suse.de as for yet unknown reason many more jobs than in before are
considered for parsing the group results on the index page and group overview
pages in specific job groups.

As more than 20k jobs are fetched from the database the query itself for job
settings is slow as well as the subsequent processing in
OpenQA::WebAPI::Controller::Main::_group_result.

This is a workaround to skip the parsing of job groups if they start with a
'~'. This way "special job groups" can be renamed accordingly to ensure
acceptable performance.

Performance was measured retrieving the index page with a database dump from
openqa.suse.de from 2016-02-26 with the command:
export date=2016-02-26; time sudo -u geekotest
OPENQA_CONFIG=local/stage_openqa_suse_de_2016-02-26
OPENQA_DATABASE=stage script/openqa get / > /dev/null 2>&1

Performance results:

• before: 15.4s
• after: 2.3s

Related issue: https://progress.opensuse.org/issues/10960

[aaannz]

Few things are not clear to me. Since there is obvious time differences and the code only skips renamed groups, what groups did you rename in yours database?
How does one uses this feature? I mean, is it like you run your setup, notice slowdown so you rename that job group to be skipped?
What are the changes in rendered page? Like group missing or so.

[okurz]

@aaannz thank you for your good considerations. My change description was not clear enough on that point. Also, as mentioned somewhere, I have problems finding the correct location where I could adapt documentation accordingly. Do we have something like a openQA administrators guide? Should we just add another document in docs?

Since there is obvious time differences and the code only skips renamed groups, what groups did you rename in yours database?

The ones that had "too many" jobs to skip, "SLE 12 SP2 9.Test Development" and "SLE 12 SP2 5.Slenkins", as both caused at least 20k jobs to be parsed for each.

How does one uses this feature? I mean, is it like you run your setup, notice slowdown so you rename that job group to be skipped?

Yes. I still have some "WIP" code in my repo which will help to find the culprit job groups but this commit on its own should help as a quick fix already.

What are the changes in rendered page? Like group missing or so.

The group won't be missing. I will be ordered in after the other jobs because of alphabetical ordering considering the "~" to come after alphanumeric. The build bars within the job group will be empty.

[coolo]

We still want these job groups in the dashboard - we just don't want 20T jobs ;)

So I'd close this

[okurz]

ok. Maybe we should have better error check and prevent openQA on choking if for whatever reasons too many jobs show up

[okurz]

obsoleted by #584