Hi AndreaT On Jul 5, 4:31 am, Andrea Tomasini <[email protected]> wrote: > On 5 Jul, 2009, at 8:43 , openwfefan wrote: > > Hi all, > > > I am also experiencing a similar issue. > > We are sorry for this, but we would need more detailed information > about what exactly goes slow, to try to figure out what we could > improve.
I agree. I will try to obtain more details about our environment and let you know. Agilo looks like a great tool and I just wanted to know if there are any quick fixes that I could do to see why agilo enabled trac instance is slower than the regular one. > > > Trac without agilo enabled page loading takes around 5 secs. > > Trac with agilo enabled the page takes around 20 secs. > > > ( this is loading the trac home page, so no tickets or backlog > > involved) > > The Home Page? There si no such thing, is it the WikiStart that you > mean? The url is https://<...>/trac/wiki BTW, I have disabled Agilo Advanced UI to make speed comparison. > > > Any tips on improving the speed would be greatly appreciated. > > There are a couple of points that I would like to make clear. Trac is > a great product, and the greatness is also in its simplicity. Trac > speed is mostly given to the fact that complex information are managed > in "smaller" bit, and never all together on one page. The whole > reports and custom query are simple DB query on flat tables, it comes > to some JOINs when you inspect a single ticket, where all the related > information need to be loaded. That's, together with the raodmap view > is about the highest level of complexity it is handling. > > Agilo is a different story, supporting Scrum properly involves to have > to deal with Backlogs, and these are not report, but Objects that you > can configure as you wish, and sort, prioritize, even decide what to > see, in which order and what to edit. A Backlog view loads a great > amount of tickets, and because it would be rather "complicated" and > painful to not use objects from a development point of view, we > developed a full API, that will be completed with the new 0.8 that is > introducing Object Identity, at least in the scope of a Request. Agilo > introduces a defined Model, View and Controller pattern, with a Model > Manager layer that allows to store and retrieve objects from the DB in > a easier and error safe way, and makes development much easier. We do > have constant performance measurement, and do at every major > refactoring some profiling sessions to check with some data inside, > where Agilo is 'loosing" time. We didn't identify any specific place, > there are though some "best practices" that you should keep in mind, > in order to make the system perform: > > 1) The Roadmap page, may become extremely slow, if you don't close > milestones. Milestones are containers of Sprints, and represent in > Agilo (and Scrum) the concept of a Release. You should plan the Sprint > needed to complete a Release Cycle into the same Milestone, when it is > finished, take care of marking the Milestone as complete. The price to > pay if this is not done, would be to run Milestone and Sprints ticket > statistics for every single item still appearing in the Roadmap, and > this is an expensive operation > > 2) Remember to configure the timeline to show a certain amount of > events per page, and than paginate, or you will also end up with > hundreds of items in there. Agilo just adds Sprints events, but if you > use other plugins - like we do - for example bitten for the continuous > integration, it is going to flood up your timeline with build > information very fast :-) > > 3) Configure the Teams carefully, and do not pack every user inside, > every time you will load a Backlog, Agilo needs to compute the > Burndown charts, which are dependent on the Team Capacity, so if there > are more people than needed inside there, it will take more time. Keep > the backlog light, by planning only what is needed, and make usage of > a Release Backlog if you want to track down what you want to release > in a specific Milestone. This Helps if you have a Product Backlog with > a lot of items inside. You may consider to do the same with the Bug > Backlog. The instances that I am comparing do not have any agilo specific information and I am not measuring the speed for Backlog or Timeline pages. > > One last note: we try to do the best we can, and more than this we > can't do... without the help of someone else :-) Agilo is Open Source, > and the great advantage of it is that you would be able to contribute > your improvement, and share them with the community. You may also > consider to join the Development Team, some already did, and the > effort to make it a better product is getting more consistent :-) > > So if you find something specific, that you think will need some more > touch, or improvement, please tell us or even better, try to fix it :-) I and my team are going to look into this next week. We will let you know what we can do > > I also suggest the one of you who are willing to cooperate for the > performance improvements, to join the Development Team to have SVN > access to the latest trunk version, so that we could check if we > already got something better in the 0.8 :-) I would love to, but right now I have other higher priorities. I will ask my team members to see if anyone can join the Development Team. I do not want to join and just be a "silent" member. > > Hope this helps, at least a bit ;-) Thank you very much for your quick reply. I will try to see what I can do to narrow done this a bit more. > > Best > ANdreaT --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Agilo for Scrum" group. This group is moderated by agile42 GmbH http://www.agile42.com and is focused in supporting Agilo for Scrum users. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/agilo?hl=en -~----------~----~----~----~------~----~------~--~---
