Scrum Dashboard - Speed Issues?

Jan 27, 2009 at 9:24 PM
I've successfully installed Scrum Dashboard 2.3 on our TFS Server, and have it working with one of our projects. However, the interface seems quite slow. I haven't seen anyone else complain about this, so I suspect it's something with my configuration, but I wanted to put this discussion out there to see.

To give an example, creating a new backlog item, or saving changes to an existing one, spends about 6 seconds on the "Please Wait" spinner. Dragging an item from one status to another takes about 5 seconds before it "snaps" to the new status box. Adding the same item through Visual Studio, Conchango Task Board, or TFS Web Access takes less than a second.

When I first installed the app, I mistakenly located my temp dir within the website's folder, and this caused an even more severe delay (12-15 seconds for the actions mentioned about) but even after correcting this, it seems uncommonly slow.

The server is a quad core xeon with 4 gigs of memory, and runs around 1-2% average CPU usage. It runs a development SQL instance and Single Tier TFS 2008 SP1, not much else.

The only place I diverged from the install instructions was that I located the temp dir on F:\scrumdashboardtemp instead of the system drive.

Could I be doing something wrong here? Or am I just being picky about the speed?

Thanks in advance,
Justin Burns, Developer
WA State Attorney General
Coordinator
Jan 28, 2009 at 7:46 AM
Well, the dashboard spends about 1 second on most of the actions in our environment - and we have pretty much the same hardware as you. It may take a few seconds if the cache is cold or TFS is up to something but not on every operation. Have you made sure that the temp folder get populated ?

We are running v2.4 Beta2 internally that contains some performance improvements, you could download it from the Release page and try it out. We have 6 teams running daily on it so its a pretty solid beta. No database changes. But I can't remember that it was as slow as 5 seconds before that.

/Per
Aug 17, 2009 at 9:11 PM

I just wanted to follow up on this issue, as I happened to stumble across the cause recently and wanted to share the solution. We had chosen not to use ScrumDashboard because of the perceived speed issue, but I had a strong suspicion that something was rotten on our end, as our problem was not shared by any other users of your software, as far as I could tell.

It turns out that the issue was entirely on the client side, and was due to the interaction of IE6 and the IE Developer toolbar. Unfortunately our agency still mandates IE6 as the standard browser (a fairly common state of affairs in government offices), and we developers had been using the IE Dev Toolbar as a means to determine control names on .aspx pages for use in functional tests. This add-on apparently causes performance in IE to go in the toilet, especially with regards to Ajax and other heavy javascript use. It had been installed on our systems for so long that we just took the poor performance for granted, as nobody was using IE6 anywhere else, and thus had no metric for comparison :)

So, long story short, we've ditched the toolbar (and are using Firefox/Firebug to support our testing, although IE6 is still the default), and we are once again planning to use ScrumDashboard as part of our development process. :)

Justin Burns, Developer
WA State Attorney General

Coordinator
Aug 18, 2009 at 8:53 AM

Great, thanks for sharing your findings.