[H-GEN] Request Tracker question

[Arjen Lentz]

Hi Byron,

On Tue, 2004-10-26 at 11:51, Byron Ellacott wrote:
> 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.

Your very own Paul Vlaar should be able to assist with the MySQL bits:
replication options, as well as tracking down performance bottlenecks.


> >>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. :)

When I was playing with RT, I found it to be a bit of a resource hog.

At MySQL (the company) we looked at RT and a number of other products
(including commercial ones). In the end we acquired Eventum, which was
about to be released. We got the original developer, and the code is now
GPL released. See www.mysql.com/eventum
We run our support system on it, and quite a few other people/companies
use it as well now. It's fully maintained.

Yes it's PHP... but you may want to get over your PHP phobia ;-) I htink
there's more wrong with the code many self-proclaimed programmers
produce than with the language as such. I come from a C programming
background, and I can produce very reasonable stuff in PHP....
Of course it's always a matter of personal preference. Quite subjective.


> > 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.


Regards,
Arjen.
-- 
Arjen Lentz, Community Relations Manager
MySQL AB, www.mysql.com

MySQL ComCon Europe (November) www.mysqlcomconeurope.com
MySQL User Conference (April)  www.mysqluc.com