[H-GEN] Request Tracker question

[Byron Ellacott]

Robert Brockway wrote:
>>RT by ticket volume; we have over 600,000 tickets in the system at the
>>RT2 does not scale to this size well.  We had to disable certain queries
> At what point would you say the slowdown became significant?

That's very hard to answer, since we imported several hundred thousand 
into RT2 when we started using it.  Slowdown does not appear to me to 
have become more significant since then, though I'm a rather light user 
of the system.  I tend to work in Trac, which is an integrated 
viewsvn/ticket/wiki system, and leave the RT2 instance for external 
communications. :)

>>because they were causing massive joins and tying MySQL up for tens of
>>minutes at a time.  We also had to pace ticket injection, because ticket
>>creation is a lengthy and heavy weight process, and a constant trickle
>>of them interferes with UI interaction.
> What about clustering MySQL and having ticket creation on a different box
> to the one the UI is touching?

This may be possible.  I'm not familiar with MySQL clustering.  However, 
from our perspective, the problem has been solved. :)  We also gained 
the ability to spool incoming ticket creation requests if we need to 
perform maintenance on the RT system.

>>Another thing to be wary of is that RT2 has a complete lack of
>>protection against multiple submits and careless reloads.  It's quite
>>easy to hit "reload" on a ticket display page, dismiss the "Resubmit
>>POST" dialog out of hand, and discover you've sent an email twice, or
>>created two tickets instead of one.
> Yes I've done this.  Fortunately (at least as far as job creation goes) it
> is pretty easy to deal with.  Just reject the job or merge it or whatever
> the policy calls for.

It's more of a problem when you start sending duplicate emails to 
external users, especially when you do it unawares.

> I don't like the assumption that everyone who is going to write additonal
> modules for RT3 is going to do it in perl and I'm looking at doing a set
> of functions for interacting with RT3 in PHP.  I'll submit this as to
> their contrib area.

I have a rather low opinion of PHP. :)

> I don't consider any of these points to be huge problems though.  We're
> still very happy with RT3.

You didn't have to migrate 600,000 tickets into it. :)  I suspect that 
might have been the biggest hurdle.  I wasn't directly involved in the 
RT3 evaluation, so my information is all second hand.

-- 
bje