Bug 729996 - TCMS Web UI is slow
Summary: TCMS Web UI is slow
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: TCMS
Classification: Other
Component: Web UI
Version: 3.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: nli
QA Contact: tools-bugs
URL:
Whiteboard:
Depends On: 734753 678610 681785
Blocks: 593666
TreeView+ depends on / blocked
 
Reported: 2011-08-11 13:56 UTC by Martin Cermak
Modified: 2012-05-23 13:29 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-21 06:57:33 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 681785 None None None Never

Internal Links: 681785

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?


Note You need to log in before you can comment on or make changes to this bug.