Performance

[eagad]

I’m currently trialing version 7 using a Docker deployment on OpenShift and I’m wondering if anyone has any recommendations for improving performance of the application. It isn’t yet clear to me where the bottleneck is in terms of speed, but the overall system feel sluggish and load times for pages are pretty long.

I’ve allocated 8GB of memory to the container and unlimited CPU. I’m using a separate virtual machine for the MySQL Server rather than hosting MySQL in OpenShift.

Has anyone tried incorporating JavaMelody with the Docker image to diagnose issues?

[Vincent Barrier]

Hello,

What did you put as Xms Xmx java options when you started iceScrum?

Regards;

[eagad]

So far, I haven’t tried setting either one. I was planning to try setting -Xmx 8G and seeing what that does. Do you have a recommendation for those settings I can try?

[eagad]

I tried using -Xms8G -Xmx8G and according to OpenShift, the pod is using 3.8 GB now. I don’t see a huge improvement on performance. 🙁

The project I am testing with is quite large, and has been using iceScrum since 2013. In reviewing the network traffic in Firefox, I noticed that doing a browser refresh causes many calls to the REST API to pull all the project data. I think there are two changes here that could improve performance significantly.

(1) Update the REST calls so that the client can request only the data they need to display instead of everything. Initial loads appear to pull data for all the retrospectives in the current release instead of just the retrospective for the current sprint. This is a lot of additional data to load that isn’t needed.

(2) It looks like doing an initial load of the page causes the data for all the tabs to be loaded at once. This is fine except that when I visit a new tab, another call is made to refresh to data on that tab. The data should either be lazy-loaded on demand as each tab is visited or the data should not be reloaded in its entirety when switching tabs. Doing lazy-loading and eliminating full reloads on tab switching would likely improve the perception of performance significantly.

I’ve tried to contribute to iceScrum in the past, but I had trouble building the code from scratch. I was told at the time to wait for v7 because it was such a big change and that the new build process was easier. Do you have a more straightforward build process these days? I’d love to be able to contribute here and there.

I really like the new version over the old one and think you all have done a great job thinking through the UI. I just need to figure out the performance issues.

[Nicolas Noullet]

We agree on your observation that in some cases too much data is loaded, often re-loaded, and this is sometimes part of why iceScrum can feel slow on big projects, but it is often not the bottleneck.

Indeed, part of the time is lost on the browser side itself when many elements are displayed, e.g. when showing a big backlog or task board. This is due to the underlying mechanisms of the framework we use (Angular) and it is not really straightforward to fix, but we are working on it.

However, we know too little about your issue to be sure about your case. Can you be more specific: what time it takes to iceScrum to display which view with how many elements?

I have answered on the contribution / building iceScrum topic on the GitHub issue you commented.

Anyway, thanks for the feedback regarding the UI and the new version, glad you like it!

[eagad]

That explains a lot. I’ve seen issues with performance using Angular on other projects as well. I’m not very familiar with Angular myself so I’m sorry I cannot offer any suggestions on that front at the moment.

I did some performance measurements and network monitoring and it looks like you are correct, there is a bottleneck is on the browser side right now. However, I do see network transfer times of 4-7 seconds for each of the REST API calls as well so there is time to be saved there too. I’m not sure how to count the elements you are interested in, so if you have a method for that, I can get that data for you too.

Thank you for your detailed reply on GitHub, I’ll respond there with my thoughts on that subject. 🙂

I’m looking forward to this new era for iceScrum with the massive improvements in v7!

[Nicolas Noullet]

4 to 7 seconds is indeed too long. Here are the way server side performance can be improved, and we most of them are already in use but they sure can be further tweaked and refined:
– database cache: store in memory data from frequent database queries, thus avoiding db query
– controller cache: store in memory the response for a given request, thus avoiding all the underlying work: logic, db query, serialization
– custom marshalling: query only part of the data for some requests, thus avoiding db queries, serialization

By saying « how many elements », I meant for example how many stories do you have in your project (you can see that on the « All » backlog in the « backlogs » view), roughly how many releases and sprints…

[eagad]

Sorry that I am the worst at replying to things in a timely manner. The project I’m testing iceScrum with is quite large. It has 2495 Stories, and 12 Releases. Each Release has about 14 2-week Sprints. I appreciate all the improvements made in the past year. I am still looking forward to build instructions that can enable those of us with development skills to help improve the software.

[Nicolas Noullet]

Hi Chris,

No problem 🙂

Regarding welcoming external contributions, my answer here: https://github.com/icescrum/iceScrum/issues/16 is still relevant. We would really like welcoming contributions but we have to invest our resources on other priorities, for instance the ongoing UI redesign, in order to stay alive and relevant.

That being said, we have implemented new performances improvements in the second-to-last version of iceScrum so this matter is still important for us.

Thanks for the numbers, this is what I would call a big project, and performance is worsened by that. If your users have a bad experience, then there is a simple and effective workaround: for the next release, creating a brand new iceScrum project to continue managing the developments. The history will still be available in the old project. Regardless of the tooling matter, we have the chance to coach agile teams and we have observed on may occasions that a « fresh start » is often very beneficial for the Product Owner and the team, and in turn for the product and its users. It does not detract from the fact that performance should still be improved, but if there is a way for your team to get a better experience then it is interesting to consider it.

[Auteur]

Messages