- General
-
Ошибки
performance getting slow
Ответ
we experience this problem also.
Its very simple because the backlog grows over time.
currently i have round about 250 single stories in my backlog.
When i started whith easybacklog it works like a charm.
In the meantime it tooks a long time to open the backlog view.
From a technical point of view i think the reason is that u do all the filtering stuff with javascript on the clientside, which gets very slow over time.
Some people of my company starting to search for a different tool just because of the performance so for me its critical currently.
Hi Roger & Torsten
Thanks for this feedback.
Roger, would not loading the archived stories you think help solve this problem for you, or are most of your stories active and live anyway?
Also, do you find the performance sluggish when using it, or just when loading it?
Also, if you could email me your slowest backlog IDs (in your URL) privately at support@easybacklog.com I will load up your backlogs myself and see if I can look into the specific performance issues. However, it would really help if you could explain where the performance issues are for you i.e. at what point do you find it sluggish?
Thanks,
Matt
Maybe it would help to 'archive' Accepted stories? I think the amount of stories is the problem. For me it also takes ages to open a backlog that we're working on for about half a year.
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.
Thanks,
Matt
Thank you very much Matt,
yes we can see that the backlog is really faster than before.
As you say its good for know but it should be better, so i really looking forward to see that tool growing faster and faster!
let me know if we can deliver more input.
Roger
Are you working on perfomance?
As it is now I thinking of finding another tool to use...
We have not had any other reports of performance issues since we resolved the issues described in this ticket. How many stories & themes do you have in your backlog? Which bits specifically are slow? What browser are you using?
Matt
I use Chrome, latest version on a Windows 8.1 OS with ok hardware...
Сервис поддержки клиентов работает на платформе UserEcho
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.
Thanks,
Matt