Bug 729996

Summary: TCMS Web UI is slow
Product: [Other] TCMS Reporter: Martin Cermak <mcermak>
Component: Web UIAssignee: nli
Status: CLOSED CURRENTRELEASE QA Contact: tools-bugs <tools-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 3.5CC: azelinka, ctang, dkovalsk, dmach, ebenes, jcai, jscotka, junzhang, llim, nli, ohudlick, pmuller, psklenar, psplicha, rbiba, slukasik, vchen, xkuang, yawli, yuwang
Target Milestone: ---Keywords: SubTask
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-21 06:57:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 734753, 678610, 681785    
Bug Blocks: 593666    

Description Martin Cermak 2011-08-11 13:56:52 UTC
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.

Comment 1 Petr Sklenar ⛄ 2011-08-11 15:40:09 UTC
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 :(

Comment 2 Petr Šplíchal 2011-08-12 07:30:53 UTC
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.

Comment 3 Chaobin Tang 2011-08-12 08:24:42 UTC
Does that appear to be slow suddenly? or it has been slow for quite a time?

Comment 4 Martin Cermak 2011-08-12 08:35:38 UTC
Chaobin, this is nothing new, the speed is constantly low.

Comment 5 Chaobin Tang 2011-08-12 09:03:32 UTC
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.

Comment 6 Martin Cermak 2011-08-12 09:26:13 UTC
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.

Comment 7 Victor Chen 2011-08-12 09:52:47 UTC
(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.

Comment 8 Daniel Mach 2011-08-31 11:37:34 UTC
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

Comment 9 Martin Cermak 2012-03-06 13:12:13 UTC
Guys, any update here?

Comment 10 yawei Li 2012-05-21 06:57:33 UTC
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.

Comment 11 Martin Cermak 2012-05-23 13:29:20 UTC
Just curious: what was the solution?