[rt-users] Merged Ticket Performance Degredation

[Damon Miller]

Hi all,

We're experiencing an issue with RT 3.6.1 wherein loading merged tickets
results in severe performance degredation, e.g. 100 - 300 seconds per
ticket.  After 30 seconds, Apache gives up on the FastCGI script and
generates a 500.  This problem has been documented and referenced in
several posts, but I have been unable to find a resolution.  The
following from Jesse seems to be the most descriptive:

"Yep. it's not recursion. It's RT::Transaction::TicketObj which should
be made smarter. Rather than loading a ticket by id, it should be
loading by id _and_ effective id. I'd love a patch."

(Full thread is available at the Gossamer list archive:
http://www.gossamer-threads.com/lists/rt/users/72384.)

I checked 3.8.1 and the "TODO" is still present in Ticket_Overlay.pm
(Load) so I'm assuming the performance problem is still present in that
release.

I'd love to help by producing a patch but frankly I don't understand
what needs to be done.  Has anyone else found a solution to this
problem?

Following another suggestion, I tried reducing the loglevel such that
the "We found a merged ticket" messages weren't stored but we're still
seeing occasional CPU spikes from the FastCGI process (and the
associated delays which lead to HTTP/500s from Apache).  Without the
debug messages turned on I can't be absolutely certain the issue is
loading merged tickets, but it seems very likely given that I can
reproduce the problem by attempting to load a known-merged ticket with
debug logging turned off.

Thanks for any suggestions or feedback.

Regards,

Damon

--

Damon T. Miller
Director of Application Services
Thinking Phone Networks
damon at thinkingphones.com 
617-649-1388 (Office)