Very slow loading of Backlogs page #698

Closed
huepf opened this Issue Sep 19, 2012 · 20 comments

7 participants

@huepf

platform:
backlogs:
ruby:

v0.9.26 of Backlogs currently loads all user stories when rendering the backlogs page which takes quite long time. The problem is that even user stories of closed sprints are loaded. We have around 3000US (most of them in closed sprints) and rendering all that information takes ~ 30sec - too long!

I suggest that only open sprints get loaded initially and only when the link "show completed sprints" the rest gets loaded as well.

@bohansen

A workaround was made some time ago. You can disable loading completed sprints in the backlog. It's called "Hide Completed Sprints " in plugin settings.
A patch/pull request implementing the described behavior is welcome ;-).

@Malti

I have same problem the backlogs takes 15 sec to load.
i 've seen the show.js.erb take between 5 - 6 sec.

@patrickmatsumura

We've checked the slow loading with New Relic and found the rendering to be the major problem. 99% of the time is burnt by the cpu only for rendering. My team and I will probably create a patch for this, since we use this plugin a lot. Also a minor performance improvement could be made with fewer queries.

@patrickatamaniuk

@patrickmatsumura i'd be interested in details of your analysis and/or the patch, of course :-)

@patrickatamaniuk

compare to Redmine Roadmap, that loads fast, even with subprojects and completed versions.

@azatoth

Takes ages to load master backlog: http://paste.debian.net/239721/

Edit: github cropped the log in half

@patrickatamaniuk patrickatamaniuk added a commit to patrickatamaniuk/redmine_backlogs that referenced this issue Mar 4, 2013
@patrickatamaniuk patrickatamaniuk load tooltips via ajax, speeding up backlog loading. #698 9042888
@patrickatamaniuk

@azatoth @huepf can you help me test the experimental branch 'optimize/loadingtime'? It contains some speedups, as far as possible without changing rails to something else... :-)

@bohansen

Nice improvement - loading time for the initial backlogs page is twice as fast now.
The menus are still pretty slow at showing up. Each menu takes approx. 2 seconds (on a particularly slow VM for testing). I guess the controller code is causing most of the delay:

Processing by RbMasterBacklogsController#menu as JSON
  Parameters: {"sprint_id"=>"321", "project_id"=>"pro", "authenticity_token"=>"..."}
  Current user: admin (id=1)
Completed 200 OK in 1765ms (Views: 15.3ms | ActiveRecord: 75.5ms)
@Cissi

We also have some performance issues when loading backlogs tab, but we have not upgraded to 0.9.36 jet, so upgrading will not solve the problem if I understand the above conversation correctly?

@patrickatamaniuk

@Cissi nice to hear from you :-)

correct, there are no performance improvements in 0.9.36. They are merged into master, though.

@Cissi
@patrickatamaniuk

next release is not planned, but march 22 would be a month's cycle since last release.
Pre-production tests are always welcome to speed things up :-) Support for redmine 2.3 would also be a reason for tagging.

@Cissi

@patrickatamaniuk So if we are about to test backlogs you want us to test current master instead of 0.9.36 since it has the performance improvement. For us both the loading of backlogs page/tab takes time, but also loading a specific story can take 10-12 seconds. But not all stories take that much time. But we are on 0.9.32 so we thought that might have been improved. The same story always takes time to load, deterministic error which is good you can always repeat it.

If master turns out good for us will you make a new release that we can use in the real production. I do not want master things in the real environment since that should be version based in my opinion.

@Cissi

I will test over the weekend and next week, we still seems to have performance issues, we will probably send you our database set-up without our real data (we have run your rake task on our database,rake redmine:backlogs:anonymize) so that you can verify and test on our database as well. Our developer will write in this issue as well more information. Where should we send the data?

BR Cecilia

@patrickatamaniuk

@Cissi loading a specific story time might be a different problem. Test data will be appreciated.

@Cissi
@Cissi

@patrickatamaniuk our developer Prasanth sent you the database by email to the address you provided for us. Vivek our ruby developer will add a description of the problem here later today.

If you want me to file a separate issue on that let me know we do it...

Best Regards
Cecilia

@patrickatamaniuk

@Cissi I can reproduce the slow loading of particular stories. The backlog view of the project containing 8 open sprints is loading reasonable fast on my master, but some! of the stories take 8-9 seconds. Lets that split into another issue here.

@patrickatamaniuk

I'm closing this at v0.9.37 - the optimizations done so far gain factor 2-3 for already optimized systems and factor 40 has been measured for a large, non-optimized system. This is as fast as we get considering effort versus developer time available.

I'm happy to see working pull requests for further major improvements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment