Description of problem: TCMS Web UI is slow. Examples: https://tcms.engineering.redhat.com/ (7s) https://tcms.engineering.redhat.com/plan/4459/ (11s) https://tcms.engineering.redhat.com/plan/4536/ (10s) My location: brq. When one has to click this websine N times a day, then the final time one must wait is N times the average page load time... This site should be minimalistic, terse, powerful, quick. Visual effects are unimportant as well as complicated components like wisiwig editors and similar stuff. Optimize the website for speed, please.
I can confirm slowness. few moment ago and I needed to see results of one case for coreutils plan: 1, https://tcms.engineering.redhat.com/ 7s 2, # search for "coreutils / general" plan and open it https://tcms.engineering.redhat.com/plan/4324/ 10s 3, open one case there and look at test plans which contain that 4, open those few test plans and each takes 10s to open. There are usually two / three 25s 5. look at runs with the results for that case so I spent 1 minute for looking at history of one single case. It starting to be more and more sleepy :(
Agreed. We spent an essential part of our QE time working with TCMS. Having to wait for many common daily actions causes quite considerable time waste. See also bug 678610.
Does that appear to be slow suddenly? or it has been slow for quite a time?
Chaobin, this is nothing new, the speed is constantly low.
Martin - I was aware of this when I first took over the project. Just wonder if it was particularly slow sometimes so that it might actually 'sleep'. TCMS was originally built as an amelioration for the then existing project Testopia. As a result, the DB schema of Testopia became the legacy for historical reason. After that, in the construction of TCMS, new schemas were also added. Eventually, we turned to have a comparably complex schema set that involved many JOINS between tables due to the inappropriate schema design. Complex JOINS made MySQL server slow, thus the whole system slow. We haven't paid that much attention to the performance of the system yet, but allow me to get back to this a little bit later.
Chaobin, this is terribly wrong. I know lots of people around me using this and it is significantly consuming their time. Our managers are willing to move important parts of Beaker tests into TCMS. We as QE will be tended to use this tool even more frequently then we do now. It's not clear to me what are you using JOINs here for. If I simplify the whole thing a bit, then basically you have test cases, test plansand test runs. That means three database tables with trivial relationships between them. MySQL itself does not suffer from slowness at all. I'm simplyfying it, I see.. I'm afraid that if you'll "get back to this a little bit later", you will have worse starting point then you have now, because current bad implementation will be even "extended". I would consider this as a priority no 1.
(In reply to comment #6) > I would consider this as a priority no 1. Chaobin, It is highest priority indeed. After we moved to the new hardware, lots of people gave positive feedback for the speed. Now it seems the problem is not resolved well. Let's focus on the problem from next release.
I believe you could get significant performance boost by using a session cookie instead of doing kerberos auth for every request. More details: https://bugzilla.redhat.com/show_bug.cgi?id=734753
Guys, any update here?
The perfomance has been improved in 3..6.3. The users feel better now. if you still has UI slow issue, please let us know.
Just curious: what was the solution?