QA (public) » openQA Project (public)

problem¶

The test details page loads very slow for big results and easily runs into timeouts.

suggestions¶

• By default we should only load content synchronously that comes from the database, everything loading from filesystem should be done asynchronously or "on demand", either later by requests from the initial page loaded or by user actions, e.g. when clicking on tabs or buttons.
• Refreshing the entire page (currently done for scheduled/assigned/setup/uploaded jobs) should be avoided.
• The query for results should not only be done asynchronously but also be splitted to prevent timeouts (similarly like modules are currently loaded on-by-one while a test is running).
• Running jobs should not be treated completely different from other jobs (like it is done now).
  • The only thing which can be avoided when a job is done is the check for status changes.

notes¶

• Of course loading from "fast" (expensive) storage like SSD or NVMe can help but shouldn't be relied upon.
• So far the table for "External results" is lot "live updated" while the job is running and only refreshed once the job is done. For reducing the immediate effort I would not change this for now.
• So far we are polling for the job state. This could be improved by using web sockets but maybe that would be over-engineering.
• Avoiding refreshing the entire page means that additional HTML elements (e.g. for the live view) need to be displayed via JavaScript.
  • It would be possible to render these HTML fragments on the server and request and insert them as needed in the client.
  • It would be possible to render HTML elements for all future job states from the beginning and hide them until a certain state is reached.
• All points mentioned here and in the sub tickets should be considered together as everything is related. Maybe improvements can nevertheless be done in steps (which raises the question where to start).

Also see https://progress.opensuse.org/issues/25814#note-15 and https://progress.opensuse.org/issues/32611#note-8