Hello, I am currently having an issue with all the default build reports in the Agile template taking a very long time to load anytime I try to run them. There are several projects with builds that I try to run the reports for. The reports will take 10 minutes at the minimum to load, or timeout before they are done loading. I've tried editing the parameters of the report to only populate within a small time frame and for a single build, but still no luck. The only time I can get the reports to pull up quickly is for a project that does not have any builds. Some of the projects are running daily and nightly builds, as well as gated. So some of them have a lot of builds that have run over the last several months. Other reports that hit the warehouse run just fine. The warehouse and cube are processing successfully as they should. I've tried running the reports during off-hours as well with no luck. Anyone have any idea on how I can optimize these build reports? We are in the process of moving more teams onto our TFS 2010 server, so there is about to be a lot more builds running. Let me know if there are more details I can provide to help. Thanks, Patrick

Hi Patrick, Thanks for your post. According your description, other reports(not build report type) all run fine, so this issue only happened in build reports. As you said that there have a lot of builds that have run over the last several months, you didnt create the Retention Policy in Build Definition to delete builds periodically? I suggest you try to delete the unneeded builds from your TFS 2010 Server, then rebuild the Warehouse and Cube, open the build reports again to check the result. Do you also have lots of builds in your CMMI team project? If yes, open the build reports(which under CMMI team project) work normally or still slow? And when the build report open slowly, please check the CPU/Memory performance on the SSRS machine. John Qiao [MSFT] MSDN Community Support | Feedback to us

We have similar issues with the CMMI Build Summary report. We have 65 build definitions, each with a maximum of 10 builds. We do not destroy build details. But we've also found that this report os very prone to slowdowns. Other (CMMI Build Quality Indicators for example) reports which use the same dimension works just fine.My blog: blog.jessehouwing.nl

Thanks for your reply. I should have mentioned that all of our builds have retention policies set. They range from keeping the latest 3-15 successful builds. I believe it is the same scenario which Jesse mentioned in that we do not destroy the build details. Also we do not have any CMMI projects. I have verified that when I try to run one of the build reports, the memory does not spike on the SSRS server (app tier). I would also like to mention that our TFS instance is running on new servers, so the hardware is not the bottleneck. So far the only thing that would make sense to resolve this would be to destroy the history of all builds. That however seems like complete overkill to me. Our teams will not want to lose their history of builds. Thank you for your continued support. Patrick

Hi Patrick, Thanks for your reply. Can you create another Team Project(Agile 5.0) under the same Team Project Collection with your current Team Project? If yes, please create it to do a test: create the build definitions in this new team project and queue them, then check build reports performance in it, work normally or slowly? John Qiao [MSFT] MSDN Community Support | Feedback to us

Hi Jess, Thanks for your reply. If you have any further research of this issue, please share your experience here. John Qiao [MSFT] MSDN Community Support | Feedback to us

The admin is troubleshooting our warehouse as soon as I have something I'll be able to share privately. @John Qiao, can I take this out of the forums and contact you or someone on the team directly?My blog: blog.jessehouwing.nl

Ok when I create a new project and have just a couple of builds that ran, the report generates more quickly. Takes about 30-60 seconds. Same goes for an existing project when I filter down to a single day and single build definition. However, running that report filtered like that provides zero value. Even when i set the filter options to be a single build for a week, it takes several minutes to run. And if i try for a larger time span or multiple build definitions to get comparisons, it takes considerably longer. Thanks, Patrick

We're seeing the same thing.My blog: blog.jessehouwing.nl

Hi, There are several tips for improving performance in Reporting Services here: Performance (Reporting Services) http://msdn.microsoft.com/en-us/library/bb522786(v=sql.100) Thanks, Cathy Miller

Thanks Cathy. However, if the issue was with reporting services performance, wouldn't the other reports be slow too? The issue seems to be with the build reports themselves. It is unclear to me whether the issue resides in the build reports themselves not being written to handle large scale TFS projects, or if the issue is with how the cube and warehouse handle the build details. Patrick

hi Cathy, I kind of understand why this was moved to this forum, but I don't really agree with the reasoning. We're talking (in our case) about a by the book multi tier TFS installation with a report server on its own box. All reports are quick and we have problems with one of the reports. The build summary report. This report and the queries are default as provided with TFS and we would expect them to be investigated and improved by the TFS team if they proved unresponsive or ineffecient.My blog: blog.jessehouwing.nl