Boost logo

Boost :

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" <> wrote:

> Dave Abrahams wrote:
>> on Sun Apr 08 2012, Steven Watanabe <> 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

Dave Abrahams
BoostPro Computing

Boost list run by bdawes at, gregod at, cpdaniel at, john at