Opened 17 years ago
Closed 16 years ago
#2570 closed defect (fixed)
Dashboard page slowing down as repository grows, trac gets more tickets
Reported by: | Vudu12 | Owned by: | richardw, khundeen |
---|---|---|---|
Priority: | normal | Component: | TracMetrixPlugin |
Severity: | normal | Keywords: | |
Cc: | Trac Release: | 0.11 |
Description (last modified by )
Dashboard page slowing down as repository grows, trac gets more tickets. Not sure which is exactly causing the problem, time to time the components and see what is taking so long.
It is taking about 5 seconds to generate the page now. We have about 450 tickets (that's not many) and our repository is not that big either, only about 8 months old, not a huge team.
Attachments (0)
Change History (7)
comment:1 Changed 17 years ago by
comment:2 Changed 17 years ago by
My original idea was to create extra database table to store the calculated statistic. However, I didn't have time to implement that part.
Time is limited at my end. I anticipated the performance issue as well but this will requires a lot more work.
Could you tell me how many tickets you have in the system and how long did it take you to load the dashboard?
Which page take more time to load? Milestone or Project dashboard?
comment:3 Changed 17 years ago by
Hi, we have more than 3700 tickets in the system and the project dashboard takes up to 10 minutes to load. The milestone dashboard is faster, under one minute to load.
Nice plugin if the loading performance of the project dashboard can be enhanced.
comment:4 Changed 16 years ago by
Owner: | changed from Bhuricha Deen Sethanandha to Richard Wall |
---|---|
Status: | new → assigned |
I have also seen this performance problem with a trac database of ~1000 tickets, ~3000 revisions.
I'll start by creating a function to build large trac databases and use it to measure the rendering time of the dashboard page. I'll then try and identify where performance could be improved.
comment:5 Changed 16 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Richard Wall to richardw, khundeen |
comment:6 Changed 16 years ago by
I haven't found solution to this problem but I did make the Ticket metrics/backlog optional in r5474. Without calculating these metrics, it won't take a long time to load.
comment:7 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I considered this ticket fixed for now. I will create new ticket when I have chance to really get into performance tuning. Metrics calculation does take a lot of cpu power. There is no easy way around this, beside disabling it all together.
We're experiencing the same slowdown (however we just installed the TracMetrixPlugin to a mature trac and repository (2 years old)). The amount of computation and database access is rather large, so obviously as we have more data the stats would take longer to generate.
If performance cannot be enhanced, I would suggest some sort of caching system. The sever could setup a cron job to generate daily stats each day (for example), and the users could view the cache instead of waiting for a live stat request.
(NOTE: If cache was implemented, users should still have the option to refresh stats now and re-generate the cache so-to-speak.)