Re: [boost] Slow Bugs Tracker

Subject: Re: [boost] Slow Bugs Tracker
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-04-08 22:49:22

on Sun Apr 08 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> Dave Abrahams wrote:
>> on Sun Apr 08 2012, Steven Watanabe <watanabesj-AT-gmail.com> wrote:
>>
>>> AMDG
>>>
>>> On 04/08/2012 09:55 AM, Olaf van der Spek wrote:
>
>>>> On Sat, Apr 7, 2012 at 3:19 PM, Dave Abrahams <dave_at_[hidden]>
>>>> wrote:
>>>>>
>>>>> I'm sorry, I thought I already posted this reply but I don't see it
>>>>> here.
>>>>>
>>>>> We've heard from people who say they've never seen a Trac
>>>>> installation with good performance.  However...
>>>>>
>>>>> IMO it will not be productive to go through an extensive analysis
>>>>> of the current performance, a review of other issue tracker
>>>>> improvement requests, or a survey of other tracker technologies.
>>>>> What we need is improved performance, ASAP.  The only way to know
>>>>> how Redmine will perform in practice for Boost is to try it.
>>>>
>>>> Beman,
>>>>
>>>> Is this ok with the steering committee?
>>>>
>>>
>>> I can't speak for anyone else, but
>>> throwing something in and hoping it
>>> helps is most certainly not okay with me.
>>
>> What does "throwing something in" mean?
>>
>> What better way is there to find out if performance is better than to
>> migrate the data and exercise the site?  If you have other
>> suggestions, please make them.
>
> Hmm - what does "The only way to know
> Redmine will perform in practice for Boost is to try it." mean?

It means... to try it.

> It sounded like what was being proposed was not a test but
> rather just moving to something else "ASAP"  I doubt anyone
> would object to some real test.  But that's not so easy. 

Really, it's pretty easy.

> I'm guessing that the performance is subtect to the size of the
> database and the configuration.  So to it's hard to make a real test
> without migrating the whole trac history

Exactly.  And that's easy.

> to the "other" system - whatever that might be.  The proposal sounded
> like "let's just do it" which is what I believe raised concerns.

Obviously, let's just set it up and poke at it until you're satisfied.

> Is it possible that the Trac is slow because of the hardware
> configuration it's being run on?  Do we have any control over that?
> Note that Source Forge offers to run Trac systems for any
> library.  I wonder what the performance would be if it were
> run there?
>
> Finally, maybe it's time to give up on the idea of a monolithic
> Trac system.  Seems to me that letting each library have it's
> own Trac system would be a small first step in the direction
> of modularization as well as solving the performance issue.
> But then, it wouldn't even be a requirement that each library
> use the same Trac system.  And it would be easy to test/experiment
> since any authors who are fed up with the current system
> could just migrate out to the one they prefer.  So if some idea
> turns out to be a bad one, the damage will be limited to one
> library to be fixed up by the person who made the change.
>
> As far as I can see, the only thing lost by this idea would
> be the ability to easily re-assign tickets. This would be
> inconvenient, but seems a small price to pay.  BTW
> I don't know this but I'm wonder if ASIO and Spirit
> don't already have their own systems for tracking bugs
> and enhancements.

The thing that's lost by this idea is any sense of being able to achieve
a substantial speedup ASAP without lots of work, experimentation, etc.
There's a script to convert Trac to Redmine.  If it works and Redmine is
fast enough, we're done solving the speedup problem.  If not, consider
alternatives.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com