I understand the points about the simplicity of the trac system and the limits on performance that that generates. We have encountered this in other 'trac situations' also.
I had some success in increasing performance. I created a fresh trac environment and migrated/massaged the tickets, wiki pages etc from one mysql database to another. Our old trac environment was the result of several past migrations and for example we had holes in the ticket numbering sequence as a result. Migrating was a pain in the ass, but once I re-linked attachments and ticket change entries, our new agilo-enabled trac environment was a lot faster. Still not the fastest, but at least usable, and the team in question is using it for active development. Im afraid I cannot pass on the 'corrupted/strange/problem-causing' database dump or trac environment as it contains too much sensitive information. I unfortunately do not have the resources or the time currently to re-create the troublesome trac environment for debugging. I have a snapshot of both the db and the trac env though, so maybe in the future. My next (and longer term) performance gain will be replacing apache with nginx+fastcgi. Thanks for the suggestions, Cheers On Jul 6, 4:50 am, openwfefan <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
