Project

General

Profile

Actions
Copy link

Bug #4349

closed

Switching tabs in the webapp is extremely slow

Added by Dennis Cabooter almost 11 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
N/A
Assignee:
-
Category:
Performance and scalability
Target version:
2.10.10
Pull Request:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

Switching tabs in the webapp is extremely slow. Sometimes it's fast, but mostly slow. I takes ~ 40 secs to switch from "Node management" to "Configuration policy", for example.

Related issues 1 (0 open — 1 closed)

Related to Rudder - Bug #4497: Rudder web UI freezes when too many inventory are received at the same timeReleasedFrançois ARMAND2014-02-25Actions
Actions
Copy link
 #1

Updated by Dennis Cabooter almost 11 years ago

To make myself more clear; the slowness when switching tabs was already on 2.6 and 2.8.

Actions
Copy link
 #2

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version set to 2.6.10

Thank you Dennis for reporting.

I don't know what could possibly do that:

Maybe some request are slow (reporting is checked for every Rule, so lots of requests, but it should be all fast or all slow, not some slow or some fast ...)

And you said to me on IRC that it was either when switching in and switching out Rule page ? or whatever page ?

Actions
Copy link
 #3

Updated by François ARMAND almost 11 years ago

Thanks for reporting.

We are trying to work on that, and to minimize things when switching. Some work was done in 2.7 and 2.8 to make things quicker. But 40s is just not bearable (so there is still A LOT to do ;)

In general, it's a given screen that is not fast, because some data are processed or badly used when it's loaded.
So, do you see that waiting when arriving on all tab ? Or only the configuration management one ? If so, does switching from Directive to Rules leads to the same time ? Does reloading Rules to ?

Actions
Copy link
 #4

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.10 to 2.6.11
Actions
Copy link
 #5

Updated by François ARMAND almost 11 years ago

An update on that one: we found #4497 that may be responsible to the behaviour described here, and could match the observed behaviour.

Actions
Copy link
 #6

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.11 to 2.6.12
Actions
Copy link
 #7

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions
Copy link
 #8

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions
Copy link
 #9

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions
Copy link
 #10

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions
Copy link
 #11

Updated by Nicolas PERRON over 10 years ago

  • Target version changed from 2.6.17 to 2.6.18
Actions
Copy link
 #12

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 2.6.18 to 2.6.19
Actions
Copy link
 #13

Updated by Vincent MEMBRÉ about 10 years ago

  • Target version changed from 2.6.19 to 2.6.20
Actions
Copy link
 #14

Updated by François ARMAND almost 10 years ago

  • Category set to Performance and scalability
  • Status changed from New to Rejected
  • Target version changed from 2.6.20 to 2.10.10

I'm going to close that one. A LOT of work was done on that subject since that time, to the extends that in 3.0, displaying the list of 2000 nodes takes ~100ms.

Actions
Copy link

Also available in: Atom PDF