We did a major deployment today, and we came across an error that was causing failed requests with Roger. It turns out that his backlog was taking just under 6 seconds to render on the server, which is completely unacceptable.
Because of the urgency of this, we've devoted a fair amount of time today to finding a solution, and we've released some updates today that have brought that rendering time down to around 1.5s, so a 4x performance improvement. Whilst this is good, this is not good enough, and we'll be working to improve that even further.
Obviously there is client-side rendering performance as well, and we'll be considering Torsten's suggestions here too, to ensure the performance remains snappy even when working with large backlogs.
Sorry for the problems, and hopefully we'll have it lightning fast again even for our heavier users. I expect you'll notice the performance improvements already.
Typically this problem seems to affect new user stories recently added since the sprint was crated and populated.
Refreshing the page fixed this.
I develop an open source project and want to make the backlog available to all interested users of the software. For that a read-only version of the backlog that can be read without login would be great.
That's an interesting idea Daniel. We've not had many people ask for this to date. You could achieve this using our API, however this would of course require some development work on your end. We'll consider the idea, however quite honestly unless more people ask for it it will be low on our priority list.
Thanks for the suggestion.
Would it help if you could just print individual stories as that may be easier & quicker to implement, or do you think that would not really solve the problem as you need to print a few stories in a batch? The problem with printing one at a time is it would be quite a waste of paper.
- Setup development environment
- Install Software
- etc etc
Служба підтримки клієнтів працює на UserEcho